Re: [matplotlib-devel] MEP26: Artist-level stylesheets
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:/
Re: [matplotlib-devel] MEP26: Artist-level stylesheets
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 the SVG spec is:
> rect { fill: red; stroke: blue; stroke-width: 3}
> But if we define the element name for a Line2D instance as "line2d"
> thenCSS snippet could just become:
> line2d { stroke: blue; stroke-width: 3}
You've just noted it: Line2D isn't a CSS selector..likewise, the properties
we want to call upon (like linewidth) are not CSS attributes. There are many
matplotlib properties that don't have an analogous CSS property/attribute
(that I know of); we might aswell define the mpl properties in our 'CSS'
subset.So we could base our language on CSS rules, but we need to define new
tokens. This means writing, or more likely, extending a parser. Not huge,
but not trivial.
R Hattersley wrote
> The DOM facade could help bridge the gap. For example, a "DOM"
> instancereturned by an Axes object could pretend to have "text" element
> children.Styling those would route the style information back to the
> underlying Axesobject. For example:
> text { font-size: 12pt;}axes text.ylabel { font-size: 10pt;}
This could be one way. Another way that would fit and I quite like is
similar to what is employed by mapnik/the tilemill, in that we simply have
nested declaration blocks, e.g:
Axes {gid: 'axes1';autoscalex_on: True;::ylabel
{text: 'Y-Axis';font-size: 10;
}}
I think this would be easier to parse and slightly clearer to read as it can
be 'attached' to the artist container it refers to (imagine if there were 2
axes in a figure...). It is also easy to write in BNF, by just adding
another option to the Declaration block:
Rule := Selector '{' [Declaration] '}'Declaration := Attribute':' Value';' |
Rule...
But...small steps. I would start by introducing something for artist
primitives and for selectively applying to primitives using the gid
--
View this message in context:
http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43673.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
Re: [matplotlib-devel] MEP13 - python containers
It seens that discussion of properties has died off, but I see it as a very important implementation for 2 reasons: 1. It will help with the implementation of stylsheets and a DOM-type model as proposed in MEP25 and MEP26 2. The act of working through the code to add properties exposes any 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 of work on artist.py, _axes.py, _base.py and axis.py Axis.py in particular is a sticking point, which has been difficult to add properties to. In any case, the fact that the Ticker() class exists points to some problems with this part of the code in particular. Ticker holds references too (or rather, the locator and formatter properties of Ticker) the axis object, yet is initialised within the initialisation of the axis class... This can be a problem. Looking through ticker.py, it seems that in most places, the need for a reference to axis is not necessary. Functions such as zoom and pan, which are within the Locator class in ticker, should actually be implemented in axis.py (as I have in my fork) as they have no dependency on Locator. Anyway, adding properties is a large job. I will probably implement them completely as part of my work, but: - Backwards compatibility will be broken - The resulting library will probably look a whole lot different to MPL. For those reasons, I doubt I will ever make a pull request for my fork and I will neglect areas such as the pyplot/pylab interfaces. IMO, have a nice simple, object oriented API negates the need for such interfaces and I am not concerned with keeping a 'matlab-user' community happy... I don't see the API of MPL changing this much anytime soon (or anytime really), but in order to keep up with newer libraries it probably should, and should not be concerned about backwards compatibility when it does... -- View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43730.html Sent from the matplotlib - devel mailing list archive at Nabble.com. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP13 - python containers
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 > review? Yes. This is mostly my inability to use git (I've not particular used it before). I'll have to look up how to clean the history and 'unversion' the unneeded freetype stuff. As it is already committed to my branch, im not sure the existing stuff can be split into chunks? But I will make issues and split up the next lumps of work. I'll post back when it is (hopefully) cleaner -- View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.html Sent from the matplotlib - devel mailing list archive at Nabble.com. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP26: Artist-level stylesheets
I have updated MEP26 to include discussion on 'decoupling' the style from
artists and having a generic Style class.
(copied over from the github issue):
I have been thinking that a good way to get stylesheets in, would be if the
'style' of an artist was entirely independent.
I.E a single property which points to some kind of 'style' object. This way,
style objects could be created on their own (programatically, or by some
other means (Stylesheets!)) and then applied to artists at will
(programatically, or by some other means (a stylesheet parser)).
Then 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://github.com/JamesRamm/mpl_experiment
Basically, it just provides a `Style` class (which is just
`GraphicsContextBase` propertified and with a new function to generate one
from a dict) and a minimal reimplementation of Line2D and Text to show how
it would be used for both.
Just run run.py (and have a look at it) to see how the user would use style
objects.
(Note it is a bit convoluted as I have not added any axes plotting routines,
so a Line2D needs to be manually created and added).
Basically, this involves reimplementing the `draw` method to use the `style`
property rather than creating a new `GraphicsContext` instance.
It also has the benefits that you could create 1 style object and apply it
to multiple artists, or tweak a couple of properties on each...which is
nicer than using individual get/set methods on artists (IMO).
So the API could potentially become something like:
arts = axes.plot(xdata, ydata) #Note not providing any 'style' info
myStyle = Style.from_dict({'color': '#484D7A', 'linewidth': 1.9,
'linestyle': 'dashed'})
arts.style = myStyle
arts.style.color = '#FF'
or:
myStyle = Style()
axes.plot([0,1],[0,1], style = myStyle)
--
View this message in context:
http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43770.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP26: Artist-level stylesheets
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 'style' of artists from their data/logic. The idea being that it heads towards a more streamlined and extensible API. Some of the techniques you are describing seem to cover some of the ideas put forth in the MEP, so if you can make the code available, it would be a great resource. -- View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43893.html Sent from the matplotlib - devel mailing list archive at Nabble.com. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
