| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
.. and parse border-image-slice with it.
|
|
|
|
|
|
| |
In particular, that's background-repeat and border-image-repeat.
Also, fix up the border-image shorthand to allow any order.
|
| |
|
|
|
|
| |
Making it a on-stack object simplifies things a lot.
|
|
|
|
|
| |
They are not used anymore. Also, it's no longer necessary to register
GtkBorderImage as a custom GType.
|
|
|
|
| |
and use it.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the toplevel we have _gtk_theming_engine_get, which lets us pass
in a property context with (atm) the size to get the property for.
Then there is a lot of plumbing to push this down into the lower
layers of the style property code until finally hitting
the property resolvers.
I need this because I will be adding a property resolver for win32
theme parts, and they render differently depending on the size
(i.e. they don't scale linearly). The idea is that the code
to get the background properties will pass in the final size
and we will resolve the theme part specification to that particular
size.
If the old non-context calls are used we just hardcode a size
of 100x100.
|
|
|
|
|
|
| |
We used to special handle gradient, but we want to be able to store
other sources (that will eventually resolve to cairo patterns).
For instance, this is needed to handle win32 theme part sources.
|
|
|
|
|
|
|
|
|
|
|
| |
It's useful to set a slice size != border-width, as backgrounds are
clipped to border-width too.
As slices can be half-transparent and overlap the background,
this would not fill the border box properly if we only use a single
property for specifying the width.
Also, this brings us even closer to CSS3.
|
|
|
|
|
| |
border-image is a shorthand, so it's unpacked unresolved and repacked
resolved.
|
| |
|
|
It's a similar private type, which is much more powerful, and respects
the CSS rendering specification for border-image.
https://bugzilla.gnome.org/show_bug.cgi?id=651194
|