jonathan: thuban/test test_baserenderer.py, 1.10, 1.11 test_layer.py, 1.34, 1.35

Jonathan Coles jonathan at jpcoles.com
Thu Feb 17 22:03:51 CET 2005


Am Donnerstag, den 17.02.2005, 20:37 +0100 schrieb Bernhard Herzog:
> The reason the tests now depend on the wxPython version is that gdalwarp
> produces output that depends on the version.  Now, AFAICT the only
> reason wx.h is included by gdalwarp.cpp is version checking and that is
> only needed to determine whether to invert the bitmask and whether it
> supports a real alpha channel.  
> 
> The solution seems obvious then: make those two flags parameters of
> ProjectRasterFile.  That way the return value of ProjectRasterFile does
> not depend on the wxWidgets version anymore and you can always test all
> reasonable combinations of those two flags.  It also makes gdalwarp
> independend of wxWidgets once again.

if i add extra options to ProjectRasterFile then those options will have
to be set somewhere. no matter where they are set it will require
querying wxPython for its version. baserenderer will have to get those
values before it calls ProjectRasterFile and then the tests that use
baserenderer will fail because the call chain will use wxPython. it's
unclear to me how this helps this specific situation. i do agree,
though, that having the options would be nicer since the version
wouldn't be determined at compile time.

do you have any ideas?

> > btw, if baserenderer shouldn't depend on any gui, perhaps it should be
> > in Model/?
> 
> One reason it's in UI is that it started out as part of the wx-specific
> renderer.  Another is that IMO rendering is not part of the data model.
> Ultimately, I think, we should refactor Thuban into more than just Model
> and UI.  Something more like Thuban.Data, Thuban.Map,
> Thuban.Interaction, Thuban.UI and perhaps Thuban.Renderers and more.
> Thuban.Interaction would be the non-GUI toolkit specific parts of
> Thuban.UI.

i think this is good idea.

> > although some things in the tests do assume a gui of some
> > sort...at least a DC...
> 
> That's why there's the MockDC and the SimpleRenderer in
> test_baserenderer.py.  The do not depend on wxPython at all and only
> provide the interface the baserenderer needs.

they don't depend on the wxPython libraries themselves, but you've
assumed that we are using wxPython because of the names of the calls
that are tested. from a practical point of view that's ok because we
only use wxPython, but from the point of view of seperating Model and UI
it's not quite right. that's all i was pointing out.

--jonathan

-- 
=====================================================================
 Jonathan Coles                               http://www.jpcoles.com
 jonathan at jpcoles.com                    GnuPG Key: /gpg_pub_key.asc
=====================================================================




More information about the Thuban-devel mailing list

This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)