Re: [matplotlib-devel] MEP26: Artist-level stylesheets
Hi James, Thanks for sharing the MEP - it's a really interesting idea, and the MEP itself looks like a good start. 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"). Do you have ideas on how one or more stylesheets would be "attached" to a particular figure, etc? Regards, Richard Hattersley -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP26: Artist-level stylesheets
On 20 July 2014 14:23, jamesramm wrote:
> 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.
>
I'm not sure what it is about CSS syntax that isn't up to the job. For
example, SVG works with standard CSS syntax (see
http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have
a 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" then
CSS snippet could just become:
line2d {
stroke: blue;
stroke-width: 3
}
Sure, matplotlib doesn't define a genuine DOM, but I understand there is
interest in moving to a model more like that. In which case, perhaps a good
way to proceed in the meantime would be to have artists expose a DOM facade
suitable for styling. (Perhaps even using SVG element conventions?)
NB. matplotlib already uses pyparsing, so it would be pretty
straightforward to knock together a parser for CSS (or whatever subset is
needed). Or there are existing Python CSS parser libraries.
> Qt - Pyside/PyQt ('QSS')
> Mapnik ('CartoCSS')
> PyGal supports stylesheets (don't know much about this library)
>
>
If we don't use CSS then +1 for using some other standard.
> 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
> >>
>
>
> 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...)
>
The DOM facade could help bridge the gap. For example, a "DOM" instance
returned by an Axes object could pretend to have "text" element children.
Styling those would route the style information back to the underlying Axes
object. For example:
text {
font-size: 12pt;
}
axes text.ylabel {
font-size: 10pt;
}
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!
>
That would be an excellent start. More complicated mechanisms can always be
added later if necessary.
Richard
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP26: Artist-level stylesheets
On 21 July 2014 14:48, jamesramm wrote:
> You've just noted it: Line2D isn't a CSS selector
CSS doesn't define any particular element names - it just operates on
element names in a document tree. So a standard CSS parser will work just
as well with "line2d { ... }" as it would with "h1 { ... }".
On 21 July 2014 14:48, jamesramm wrote:
> ..likewise, the properties we want to call upon (like linewidth) are not
> CSS attributes.
Agreed - not all properties are standard CSS properties, so I was
suggesting borrowing SVG properties to augment the list. NB. That would
make the property controlling line width be called "stroke-width". But
whatever names we choose, a CSS parser doesn't care what the names are.
But really the issue is not so much about CSS and SVG-styling-properties -
it is whether to use existing standards or not. Clearly I'm in favour of
adopting standards. But perhaps there is another standard set of CSS
styling properties which would be a closer match to matplotlib? Perhaps CSS
is not the answer at all, and something like SLD/SE would be better? (I
suspect not! But there could easily be other technologies I'm not aware of!)
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...)
In the case of two Axes, the CSS version would be:
Axes#axes1 {
border: 1px solid black;
}
Axes#axes2 {
border: 2px dashed green;
}
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP26: Artist-level stylesheets
On 21 July 2014 17:40, R Hattersley wrote:
> In the case of two Axes, the CSS version would be:
>
> Axes#axes1 {
> border: 1px solid black;
> }
>
> Axes#axes2 {
> border: 2px dashed green;
> }
>
>
Or if you want to borrow from more advanced selector syntax, you could do
fun stuff like:
Axes:nth-child(odd) {
border: 1px solid black;
}
Axes:nth-child(even) {
border: 2px dashed green;
}
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] using waffle.io for issue management
You need an extra "matplotlib" ... https://waffle.io/matplotlib/matplotlib On 17 January 2015 at 19:29, Thomas Caswell wrote: > Hey all, > > We have set up waffle.io to try and help manage our issues: > https://waffle.io/matplotlib/ > > If you have commit rights, you should be able to move the cards around. > > Any thoughts on this tool? I would like to use this to keep track of the > review state of PRs. > > Tom > > > -- > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
