Re: optional policy

In article <[email protected]>, Dallas Johnston
<[email protected]> writes
>Robin Becker <[email protected]> wrote:
>>this may be true, but all the import analysers see it anyway and add it
>>automatically whether it's needed or not. The frontends & dialogs are
>>imported in __init__.py. Whether they get used or not is moot.
>
>Ok, while this is true for the Dialogs it is definitely not the case for 
>ComboBoxWapper. If you look at the code in ComboBoxes.py you will see the 
>following:
>
>def wrapperFactory(self):
>        try:
>            return backendModule().ComboBoxWrapper(self)
>        except(AttributeError):
>            return frontEndWrappers().ComboBoxWrapper(self)
>
>

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.

>
>>>I just didn't do the same with the anygui dialogs, as I thought that it would 
>be 
......
>
>Well, that is why we could have _had_ Anygui*Dlg so that the authors _could_ 
>make the choice. The "Anygui" part of the name did have a meaning for this very 
>reason: to discern backend-independent dialogs from backend-specific 
>implementations. Anygui app writers could thus choose their tool at coding time. 
>(uniform look and behaviour vs. things of all shapes, sizes and sundry 
>functionality)
>

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.

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.

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.

>But not all backends have native dialogs. This was really the whole point of 
>writing them. For instance, is there an official generic About dialog in Tk, or 
>generic Win32 About dialog (and i'm not talking about wizard generated MFC about 
>dialogs here). I think not. It is in such cases that having a frontend 
>AnyguiAboutDialog would save everyone from having to code one in the backend.
>
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.
-- 
Robin Becker


-------------------------------------------------------
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