It would be great if we can see the code for the style system.
However, for integration into MPL, rather than something which 'sits on top'
of the existing API (I presume you are therefore working with getter/setter
functions), the MEP I'm proposing is also trying to achieve the seperation
of the
n I thought...when it comes to drawing, the style **is** entirely
independent - it has been transferred to the `GraphicsContext` object. So
all that is needed is to expose this object at the artist level and we can
create styles!
I created a very minimal example to explain here:
https://githu
Thomas Caswell wrote
> I only took a brief look at that branch, but two comments
>
> 1) can you clean up your git history, you are adding 20k new lines (of
> mostly freetype and random files that should not be tracked)
> 2) can you split the propertify work up into chunks that are easier to
> revi
inconsistencies and vulnerabilities.
I have been adding properties to my fork of MPL as part of the development
of a visualisation tool.
https://github.com/JamesRamm/matplotlib/tree/master/lib/matplotlib
text.py and font-manager.py are completely 'propertyfied' and I have done a
fair amount
R Hattersley wrote
> I'm not sure what it is about CSS syntax that isn't up to the job.
> Forexample, SVG works with standard CSS syntax
> (seehttp://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just
> havea different view of what constitutes CSS vs. HTML/SVG/whatever.The
> example in
Nelle Varoquaux wrote
>> I'd strongly encourage you to stick with standard CSS syntax/behaviour
>> instead of extending it. For example, the selector of "Axes.ylabel" would
>> be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label").
>>
>
> I actually think we need to focus on something e
