Re: optional policy

Robin Becker <[email protected]> wrote:
>while this may be true, the unconditional import of frontend_wrappers in
>anygui's __init__ causes ComboBoxWrapper to be imported anyway. The
>reason why I noticed this is because all of the pycs get created ie the
>files actually got imported.

As I said in my previous mail, this can be done easily by moving the import code into the wrapperFactory method. Also, all the *.pyc bytecode files are created at anygui *setup* time (byte compiling foo...), not at import.

>So let's just define an  anygui backend which implements everything that
>isn't implemented by some other backend. I guess that's what I really
>against here. The layers seem to be congealing together which I think
>anygui is supposed to be against.

I don't think that this is what I'm suggesting. I just simply recapitulated what it was that had already been descussed concerning providing frontend versions of certain widgets and dialogs that do not exist in some of the backends. This keeps those backends from having to code it themselves.

>We don't seem to have any abstract dialog classes for the backends to
>implement.
>
>So we really need an abstract Dialog class for each of the dialogs which
>are to be standard.

I agree. I've always agreed here. But I also thought that it would be cool to let the developer decide which to use, like in the case of AnyguiOpenFileDialog. Some people may find that they want consistency across backends, as opposed to having the layout of the dialog change on every platform.

>Then I assume the setup for any abstract class can choose to obtain a
>wrapper from the backend. If the backend can't supply a wrapper then
>surely the backend() can supply a generic if such exists. That is a more
>generic way of doing this. If required the backend can support the idea
>of using the generics before the native as a user choice.

Ok. I see your point. I'm assuming that you want to move the class selection into the backendModule() function [not backend()], and then have the user specify *Dialog(version='frontend') or *Dialog(version='backend'), the latter being the default? But I don't think that this is all too different than allowing them to instantiate the object specifically via Anygui*Dialog(), as opposed to the backend version via *Dialog(), and having creation resort to the Anygui*Dialog version when the native one doesn't exist.

>there are standard dialogs (indeed supposedly native ones) in Tk and in
>ms they just haven't been implemented.
>
>I'm not against the possible generic things, I just think they shouldn't
>be part of the default anygui only the abstract part should normally be
>generic. That will encourage the backends to support the proper front
>end.

I believe this is exactly what I am talking about. Again, and forgive the belabouring here, doing with *Dialogs as I did with ComboBox, only allowing the user to choose dialog version via class name, not an __init__ parameter.  This type of change would only literally take a few minutes to setup.

--Dallas

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html