On Sat, Jun 14, 2008 at 02:07:10PM +0100, Tom Hennigan wrote: > > On 13 Jun 2008, at 23:18, Youness Alaoui wrote: > >> >> >> 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... > He needs to run it from a bundle, rather than just python amsn2.py. > (Otherwise the nibs won't load properly, which build the interface). > There's a file in the root dir called setupCocoa.py, all he does is: > python setupCocoa.py py2app -A > And then he can run the application from dist/aMSN2.app > All there is so far is the login window, and a logging in screen. No > contact list yet. I'll work on this in a week, as I have exams at the > moment. > > - Tom > ok cool! thanks for the answer.. I forgot about setupCocoa.py.. I'll pass along the message. Thanks! KKRT
>> >> - 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 ------------------------------------------------------------------------- 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
