aesthete-team team mailing list archive
-
aesthete-team team
-
Mailing list archive
-
Message #00052
Re: Plot patch to change data limits
With first patch, looks good, but have had to add a small workaround for
matplotlib API change
> Okay, another patch, which allows one to set the resolution of the Glancer
> window. All plots within that Glancer window share this resolution, but
> (hopefully) plots in other Glancer windows do not. It seems a bit messy but
> it's the best I could come up with.
>
Had to think through this - resolution was a property of lines because
originally I was thinking in terms of Source always capable of providing a
set of data-points. However, after a bit more thinking, given the emphasis
on functions, it makes more sense to actually make this a property of the
Line and pass it as a parameter to the Source when generating a data set.
If the Source is discrete, it ignores this parameter.
So, I've used your code and adjusted it a bit to cope with that change.
Looks like you're figuring out the property system. Couple of esoteric
notes:
In get_foo, the 'val=None' parameter is used to cast; val will either be a
string, or the correct type, but in either case, get_foo(val) (for
val!=None) should return the value in the storage type, e.g. int(val). val
will be passed through here before it's passed to change_foo, so change_foo
should always receive a parameter of the correct type and doesn't need to
do casting itself (if it does, there's a bigger bug lurking).
On a related point, change_foo is not set_foo because it shouldn't be
called directly. Instead, using change_property('foo', bar) will
simultaneously notify anybody expecting signals about changes to foo (e.g.
any relevant aes_method_entry widgets). For instance, I've just created a
member,
def set_resolution(self, res) : self.change_property('resolution', res)
Hope that clarifies/mudifies some stuff!
P
Follow ups
References