Hi, As soon as you said "I have a doubt about the design of amsn2" you lost me... :p Anyways, you're right, but all that you said isn't against the design. For now the base classes are simply 'templates' (empty interfaces) because there is nothing common to all front ends, but if you find something that should be common to the templates, then yes, it *can* be put in the base classe, like you described... however, my question would be : why ? why would you put that common thing in the base class? If it's something common, then it should be in the core...why not put the account_views in the core, and the getAccountViewFromEmail in the core too? and leave the front end classes to have only the UI specific tasks ? KaKaRoTo
On Mon, Jun 22, 2009 at 8:31 PM, Pablo Castellano <pablog.ubu...@gmail.com>wrote: > Hello there. > I have a doubt about the design of amsn2. > > First, well... we all know that want amsn2 to be front-end independent, > but while I am coding I feel like there should be some more things > commons to all front-ends. > > For example, we could impose all login windows implementations to have a > self._account_views variable to store all accountviews that will be > displayed in the login screen. > This way, we could also have the self.getAccountViewFromEmail(email) > method that finds the accountview from the selected email in the > combobox (or whatever it is depending on the front-end) because that > function knows that the list of accountviews are stored in > self._account_views. Besides, after all we are not restricting the > freedom to implement your favorite front-end as you want, because I'm > (almost?) sure that every front-end will need it (correct me if I'm > wrong), and so all frontends could use it. > > I think that at this point that the matter is clear. > But now the problem is that we have the class aMSNLoginWindow from which > every login window implementation inherits (I'm talking about the one > defined here: amsn2/gui/base/login.py). We could define all common > methods there, but I don't think it is the right place. I understand > that those files (amsn2/gui/base/*.py) are the base for every > implementation: they are templates and they are essential for anyone > that wants to make his own front-end for amsn2 and wants to know which > methods he has to redefine. Aren't they for that purpose? > So if everyone agree, we should now determine if it should be created a > new superclass (in this case for all login window implementations) and > leave the base there as is. Or on the contrary we (*I* this time) should > write all common methods/variables there, in the base. > > To see what I'm talking about see my last commit here: > > http://github.com/PabloCastellano/amsn2/commit/fc794680ccbbda7801fbbda9b91314d8ea4c2a7e > > Any idea? Am I wrong about anything? > > aMSN2 lives. > -- > Regards, Pablo. > > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge > conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: > $250. > Need another reason to go? 24-hour hacker lounge. Register today! > > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel >
------------------------------------------------------------------------------
_______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
