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 easy to parse and easy to
> use, not necessarily stick to the CSS syntax and behaviour. Back in the
> day
> where I was doing web development and design integration, everyone seemed
> to hate CSS, so I am a bit curious and dubious about this choice.
We cannot stick with the 'standard' CSS syntax by necessity, simply because
the standard CSS selectors and properties are defined from HTML and do not
match with matplotlib.
I.E we want to select by artist type, which doesn't exist in HTML and use
properties such as linewidth.
So, we would need to define a new syntax based on these tokens.
I have updated MEP26 with a BNF form of a basic syntax to use - take a look!
Another option would be to use the syntax for the ConfigParser module; this
way we already have a parser :)
Nelle Varoquaux wrote
> I think we need to be careful about the choice of the grammar and the API:
> we know there are tools that are "doing it right", and tools that aren't
> (matplotlib falls in the second category). Before trying our own recipe I
> suggest that we look elsewhere, on how other libraries are tackling this
> problem, to see if we can reuse some of the good ideas and avoid errors. I
> am thinking in particular about ggplot2 (which I have never used, but I
> hear is very nice).
>
> Thanks,
> Nelle
I thought CSS would be a good language to base it on as it is a widely known
and by far the most popular (as far as I know) 'stylesheet' language.
Other libraries that use style sheets, based on some form of CSS are:
Qt - Pyside/PyQt ('QSS')
Mapnik ('CartoCSS')
PyGal supports stylesheets (don't know much about this library)
As I say, an alternative could be simply using the ConfigParser
Richard Hattersley wrote
>>
>> Do you have ideas on how one or more stylesheets would be "attached" to a
>> particular figure, etc?
>>
>> Regards,
>> Richard Hattersley
>>
This is the big question. We need a standard way in which to traverse all
the artists in a figure, filter them by the selectors and applying the
property updates.
The last part is easiest - the update() method on artists will accept a
dictionary. We can simply ensure that our stylesheet rules are parsed into a
dict structure (which is quite a common method to use).
The hard part is
a) Getting a complete figure description/traversing the artists.
This is currently tricky, but I think the ideas proposed in MEP25 will make
it much easier.
b) Filtering artists
Another problem is that we would generally want to treat artists which are
solely for the construction of the Axes differently to those artists that
define a plot. I.E we might want to define Line2D as having the colour red,
but we want lines which compose the Axes to be black or grey.
My initial proposal is to develop stylesheets for artist primitives only.
But eventually we will want to style artist containers aswell.
The problem matplotlib has is that the properties for artist containers are
not uniform/intuitive.
It generally has a API where artists which are 'contained' by other artists
are set by calling properties...e.g. axes.set_ylabel(text = , etc...)
I would prefer to be able to simply pass a class instance...e.g create an
instance of Text() and pass that to set_ylabel()
I believe this is similar to the Plotly API that is quite nice:
https://plot.ly/python/line-and-scatter/
An ideal solution would be trying to seperate out the style of artists from
the actual drawing/data
PyGal accepts a `Style` instance as an arguement to it's plotting functions,
which would be a good way to go.
I would imagine setting stylesheets through the axes or figure methods
(axes.setStyleSheet() or figure.setStyleSheet()). Via figure would require
being able to differentiate between different axes - i.e. introducing the
'container' level syntax I mentioned above.
I would imagine that this would eventually replace rcparams to define the
default style. I would also like to see the default look of graphs moving
away from the very dated, 90's style MATLAB appearance!
Anyway, there are a lot of ideas above, some of which are feasible, some of
which perhaps not, all of which need more thinking about!
--
View this message in context:
http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43671.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
