If you look at the following dialogs in Util: ok, okCancel, yesNo,
yesNoCancel, their APIs are functionally subsets of wx.MessageBox,
however, the wx.MessageBox API is more convient and flexible.
Perhaps whoever wrote these APIs didn't know about the wx.MessageBox
API, otherwise I suspect they'd just use it -- or at least not require
the usually unnecessary parent argument and implement their new API
variations with wx.MessageBox.
One of Chandler's strengths is that it includes many different open
source libraries. When one of those libraries has an API that is right
for the job, I think we should use it, only including new layers of API
if they provide a real tangible benefit. This eliminates code that we
would otherwise have to document and maintain.
It's probably much more likely that a Python programmer coming to the
project will be familiar with wx.MessageBox API than the Chandler
variants. When one of them asks us why we didn't just use wx.MessageBox,
I hope it isn't just because we didn't know about wx.MessageBox.
John
Grant Baillie wrote:
On Jan 6, 2006, at 18:27, John Anderson wrote:
I think that exposing wx as a public API is a bad idea, it should
just be an implementation detail.
Does that mean for every wx routine that a parcel writer could use
use we have to implement a wrapper routine? That's potentially a
large portion of wx.
IMHO, you should be able to write a fairly basic parcel without
needing to know wx; i.e. we should cover the most commonly
encountered dialogs. Curiously, if I were to come up with a list of
those, it would pretty much match what's in Util.py.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
