On 6/13/08, Tom Hennigan <[EMAIL PROTECTED]> wrote:
>
> The plugins system is crap lol. Please re-write it. It is bad python.
>
hehe! no problem! even if it's crap you still did something :p Alen said
that he has a good plugin system for elloquence, we might use that.. or look
at emesene's plugin system... although I think right now
we should leave plugins support at the end!
And the cocoa gui (so far!) is a poc. I will rewrite this after next week
> (when my exams finish :-D)
>
yeah but it's still there... just like any other front end, they are all
PoC... btw, a mac user is cocoa crazy and he wasn't able to make it work,
looks like getMainWindow returns None...
- Tom
>
> On 13 Jun 2008, at 19:09, Youness Alaoui wrote:
>
> hehe,
> yeah, it's getting more interesting with the many new developers (welcome,
> if I didn't say it before:p)!
> Actually, Tom wrote a plugins system, and did the cocoa GUI, so I wasn't
> alone in there :p
> And lephilousophe helped a lot with the design and did the initial proofs
> of concept for gtk and QT during the 'investigate the proper toolkit' phase
> (way before any real code or ui abstraction).
> Then jandem did the gtk front end and now profoX is doing the QT front end!
>
> KaKaRoTo
>
>
> On 6/13/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
>>
>>
>>
>> 2008/6/12 Youness Alaoui <[EMAIL PROTECTED]>:
>>
>>>
>>>
>>> On 6/12/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>>> wrote:
>>>>
>>>> That's genius :) It's like a huge cake of abstraction! I love it - this
>>>> way front-end developers can concentrate on what's important to them! This
>>>> modular approach also means the team can be so much more efficient!
>>>
>>>
>>> Thanks!
>>>
>>> Great work everyone who worked on this, it's looking good for the future!
>>>
>>>
>>> me :(
>>>
>>
>> You brave soldier ;) Don't worry, looks like everything is set to become
>> much more active!
>>
>>
>>>
>>> Tom
>>>>
>>>> 2008/6/12 Youness Alaoui <[EMAIL PROTECTED]>:
>>>>
>>>>> Hi All,
>>>>>
>>>>> This email is to explain a bit the design and structure of aMSN2.. so
>>>>> it's leaning more towards developers than towards users...
>>>>> As I explained in my previous mail, the design is simle :
>>>>> 1 - three layers : protocol, core, gui
>>>>> 2 - the protocol is taken care of by pymsn
>>>>> 3 - the gui is abstracted and any front end can be used (multi-front
>>>>> end client)
>>>>> 4 - the programming language is python...
>>>>>
>>>>> So for the technical details, first, download the source code. I've now
>>>>> imported it into our public SVN, and you can get it from the SVN URL :
>>>>> https://amsn.svn.sourceforge.net/svnroot/amsn/trunk/amsn2
>>>>> You will see the three layers in the amsn2 subdir, we have :
>>>>> gui/
>>>>> core/
>>>>> protocol/
>>>>>
>>>>> The idea is that the protocol layer will be the glue between pymsn and
>>>>> the core, it will receive events from the core and notify pymsn, and it
>>>>> will
>>>>> receive events from pymsn and notify the core.
>>>>> This allows for one thing : modularity! I do not want to have code
>>>>> mixed everywhere again like we had with aMSN 0.x... This would also 'in
>>>>> theory' allow for switching to a different protocol or to a different
>>>>> library, BUT we do NOT want to do this. It was decided that aMSN is an MSN
>>>>> clone and if you want a multi protocol client, there are many good ones
>>>>> out
>>>>> there.. we want to concentrate on the MSN protocol so users can have a
>>>>> fully
>>>>> featured client, we want all our efforts to go into MSN compatibility. End
>>>>> of the discussion!
>>>>>
>>>>> The GUI layer takes care of all our GUI needs, we have a 'manager' that
>>>>> basically stores which front ends we have installed and allows us to
>>>>> access
>>>>> their classes... a front end can register itself from anywhere by calling
>>>>> the guiManager.registerFrontEnd, and giving it its module
>>>>> (sys.modules[__name__] ).
>>>>> Alen has maybe a different idea about this and we'll see what he comes
>>>>> up with, so this design can change a little...
>>>>> NOTE that everything so far is in proof of concept mode and anything
>>>>> can change at any time!
>>>>> The way I see the front ends is a bit like a set of mega widgets... or
>>>>> an 'abstracted toolkit API' but higher level...
>>>>> I will talk again about front ends once I explain the core a bit...
>>>>>
>>>>> The core.. the most important thing out there.. that's the heart of
>>>>> aMSN2, we want every front end to act the same, to have the same features,
>>>>> and this will be accomplished thanks to the core! The core is the glue
>>>>> between the protocol and the UI, it will take care of profiles,
>>>>> configuration, options, non-protocol/ui features, etc...
>>>>> The most important part of the Core in terms of the other layers is the
>>>>> 'views' concept. This design will allow us to have a really nice client,
>>>>> easy to build new front ends, and a consistent feature set amongst all the
>>>>> front ends...
>>>>> What is a View? Well it's simple, it's how we want the user to 'view'
>>>>> our UI. For example, the GUI doesn't need to know if a contact is online,
>>>>> away or busy.. the UI doesn't need to know a contact's nickname or psm,
>>>>> or a
>>>>> group's "count/total".... the UI only needs to know *what* to show the
>>>>> user... If we tell the UI to show a specific icon (depending on the state)
>>>>> for a contact, as well as what 'name' to give the contact (including the
>>>>> PSM.. or not, depending on the user's options)... and if we tell the UI
>>>>> that
>>>>> the group's name is "X (count/total)".. that's all it really needs to
>>>>> know...right ?
>>>>> well, that's what the views are all about, they tell the UI how to
>>>>> display an object...
>>>>>
>>>>> So there's this magical thing that I called 'StringView'... it's a
>>>>> 'view' on a 'string'... basically, it's a list of elements specifying how
>>>>> the string should be displayed... A StringView can be something like this
>>>>> :
>>>>> list : color red text "my nickname" image <img> text "<-- that was a
>>>>> smiley" color grey text "(away)" color red text "\n" italic true text
>>>>> "psm" italic false
>>>>> (the stringview can also contains tags...)
>>>>>
>>>>> With a StringView we can represent anything we want.. the nickname of a
>>>>> user, including smileys, including status, including the psm, etc..
>>>>> The reason why we do it like this is because :
>>>>> 1 - we don't want every front end to have code for parsing the smileys
>>>>> (what about custom smileys)
>>>>> 2 - we don't want every front to need to access the user's preferences
>>>>> like "show psm beside the nickname"/"show psm under nickname"/"don't show
>>>>> the psm"
>>>>> 3 - the UI doesn't need to know the status/whatever of a user, it just
>>>>> needs to know *how* to display it.. because that's what the user will see
>>>>> in
>>>>> the end...
>>>>>
>>>>>
>>>>> So.. now that you know about the StingView, let's talk about
>>>>> ContactView.. as you can see every ContactView has a unique identifier
>>>>> representing the contact.. an 'icon', which will be an Image that gets
>>>>> built
>>>>> by the core (using the front end Image class API).. it can be a buddy icon
>>>>> depending on the status or the display picture (depends on the user's
>>>>> options), it can also contain 'emblems' like 'blocked', or 'away' emblem
>>>>> on
>>>>> top of the display picture, or a 'alarm' emblem if the user has one...
>>>>> We do not want the front end to need to look through the options, or to
>>>>> query the core for whether a contact has an alarm or not, or query
>>>>> the protocol to see if the contact is blocked or not....
>>>>> The ContactView also has a 'name'.. that's a StringView to represent
>>>>> the contact.. it will contain the nickname (or custom nickname), parsed
>>>>> smileys, the psm (depends on option)... the color of the nickname will
>>>>> depend on the status of the contact, or depends if the user sets a 'custom
>>>>> color' on the user.. etc... You now understand that we don't want every UI
>>>>> to start checking if the user has set a custom nickname for the user, or
>>>>> if
>>>>> there's a global custom nickname (or psm), or if he has a custom color for
>>>>> the user, etc...
>>>>> The ContactView also contains a 'dp' attribute which is an Image with
>>>>> the display picture of the user... the reason why this is different from
>>>>> the
>>>>> 'icon' attribute is because we might want to show them both.. for example
>>>>> :
>>>>> [icon] nickname [ display ]
>>>>> psm [ picture ]
>>>>>
>>>>> Like pidgin does for example... whether that attribute contains the DP
>>>>> or nothing will depend on the user's options again...
>>>>> Finally, we have a 'menu' which is the contextual menu when you right
>>>>> click on the user (it's a MenuView item describing what the menu contains)
>>>>> and a 'tooltip' which is a TooltipView on what to show in the tooltip...
>>>>>
>>>>> Now, I'll expain what the GroupView class is... it's a view on a
>>>>> group.. hehe.. it's the same thing again, the unique id, the icon (will
>>>>> change from collapsed to expanded icon), the name (StringView containing
>>>>> the
>>>>> name of the group + the count/total), menu and tooltip.. but we have
>>>>> one more item : 'contacts'.. it's an ordered list
>>>>> of the contacts contained inside that group...
>>>>>
>>>>> The other view classes are pretty much self explanatory...
>>>>> Now, we move the front end.. the front end is given to the core as a
>>>>> module object, the module contains all the classes we want/need and the
>>>>> core
>>>>> creates them as he needs...
>>>>> Any front end should implement the amsn2.gui.base.* classes, we have a
>>>>> few classes in there, it's not that complicated :
>>>>> mainloop : this is just an abstraction over the main loop.... pymsn
>>>>> needs the glib mainloop (hopefully removed soon), but you might want to
>>>>> run
>>>>> the qt/gtk/efl main loop, depending on what toolkit you use.. you
>>>>> implement
>>>>> this here...
>>>>> main : the main window, this window will contain the login screen or
>>>>> contact list... the login window and contact list windows will need to use
>>>>> this window to show themselves inside of it.. why.. because we don't want
>>>>> to
>>>>> have a window appear/disappear when you start logging in...
>>>>> image : simple class to abstract an image.. use whatever library you
>>>>> want to represent an image.. (QImage? gdkpixbug... etc...)
>>>>> login : this is the login window... the base classe has documentation
>>>>> on each function.. it should be straight forward... this implementation is
>>>>> not yet finished, as we need a way to feed the login window the list of
>>>>> profiles as well as the list of "sign in as " statuses for each profile
>>>>> (if
>>>>> a profile has a saved custom state)....
>>>>> contact_list : this is the interesting one... the base classes
>>>>> functions are documented so it should be simple but I still want to
>>>>> explain
>>>>> this a bit :
>>>>> When you look at the api, you will notice something, there are only 4
>>>>> functions :
>>>>> contactUpdated, groupAdded, groupRemoved, groupUpdated...
>>>>> You might be asking "humm.. why isn't there a contactAdded,
>>>>> contactRemoved, etc...", well, it's simple... here's how it would work, on
>>>>> initial connect, you get a bunch of calls to groupAdded with the groups of
>>>>> your contact list, in each of those groups, you have the contacts
>>>>> (remember,
>>>>> GroupView.contacts), so the front end gets this, and displays the group
>>>>> with
>>>>> its contacts...
>>>>> in every possible scenario of the contact list getting modified, the 4
>>>>> functions are enough to make the UI sync with the protocol...
>>>>> nickname changed : groupUpdated + contactUpdated ( the groupUpdated is
>>>>> called if the sorting is done by nickname, so the front end gets the new
>>>>> ordered list of contacts and it reorders the contacts in the UI)
>>>>> psm changed : contactUpdated
>>>>> status changed : groupUpdated + contactUpdated (the groupUpdated
>>>>> because the sorting can be done on status, or if the user goes offline
>>>>> (if
>>>>> we group offline contacts together, then we get groupUpdated for both
>>>>> groups) the 'name' (count/total) of the group might also change, and
>>>>> contactUpdated because the '(status)' or color might change)
>>>>> new user : groupUpdated (the list of contacts has one more, the UI adds
>>>>> it when it synchronizes the UI list with the groupview.contacts list)
>>>>> deleted user : groupUpdated (same as above)
>>>>> contact blocked, unblocked, etc... whatever : contactUpdated
>>>>> sorting changed (ascending/descending/alphabetically, etc..) :
>>>>> groupUpdated
>>>>>
>>>>> etc...
>>>>> What this means is that the sorting is of course left to the Core.. the
>>>>> core decides on how to sort the contacts, etc.. it's not the UI's job..
>>>>> but
>>>>> it also means that the UI must keep on each group widget, the ordered list
>>>>> of contacts that are shown with their unique id, so it can resynchronize
>>>>> itself when it gets a groupUpdated... of course, you can just delete all
>>>>> contacts from the UI and rebuild them.. but try to be optimal in terms of
>>>>> performance please... thanks...
>>>>> This also means that.. I know, you won't like it.. but! it is
>>>>> necessary... when a user clicks on a group, you must NOT collapse/expand
>>>>> it.. you must tell the core about that event and let the core decide...
>>>>> sending you a groupUpdated() with an empty list of contacts in the
>>>>> GroupView...
>>>>> The reason is simple :
>>>>> 1 - the GroupView gives you the 'icon' for the group.. and that's
>>>>> what's deciding if the icon is expanded/collapsed...
>>>>> 2 - imagine an option 'never collapse groups'... we don't want a UI
>>>>> that ignores that option...
>>>>> 3 - imagine the option on a contact "always show this contact"... so we
>>>>> would want a 'collapsed' group.. but still showing a contact...
>>>>> 4 - what about 'collapse/expand' on double-click only...
>>>>>
>>>>> to be able to do all that, we need the UI to work this way! I know that
>>>>> for some toolkits it will be easy/intuitive but for others (like gtk with
>>>>> its treeview) it will actually involve more work... sorry about that!
>>>>>
>>>>> Also please note that *for now*, we don't have all that working...
>>>>> humm.. yeah.. there's not much done with the icons.. the protocol doesn't
>>>>> do
>>>>> much.. there is no "group_clicked" or anything like that yet.. so be
>>>>> patient
>>>>> and we'll try to make the core evolve as fast as possible...
>>>>>
>>>>> any comments are appreciated!
>>>>>
>>>>> Thanks for reading!
>>>>> KaKaRoTo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> Check out the new SourceForge.net Marketplace.
>>>>> It's the best place to buy or sell services for
>>>>> just about anything Open Source.
>>>>> http://sourceforge.net/services/buy/index.php
>>>>> _______________________________________________
>>>>> Amsn-devel mailing list
>>>>> Amsn-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> Amsn-devel mailing list
>>>> Amsn-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>>>
>>>>
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Amsn-devel mailing list
>>> Amsn-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Amsn-devel mailing list
>> Amsn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>
>>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://sourceforge.net/services/buy/index.php_______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
