GTK+ added a new PolicyType which currently triggers compiler warnings
about unhandled values in switch statements. We also have a use case for
it already, so add support for the new policy type.
https://bugzilla.gnome.org/show_bug.cgi?id=739379
It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
If enabled, scrollbars take away from the allocation given to the
view's content. This is usually preferrable to painting the bars on
top of the content, but there are exceptions, for instance when the
content needs to be centered with regard to the view as a whole.
Add a :overlay-scrollbars property to account for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
Reposition the window overlay when the title changes, using the current
transformed size of the window clone.
Includes a test that changes title to a string of random length every 3 seconds.
Based on a patch by Alex Hultman <alexhultman@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=620874
Add support for the CSS "background-repeat" property. Currently, this
only supports on/off, rather than allowing tiling in each individual
dimension. It is supported for both the cogl and cairo rendering paths.
https://bugzilla.gnome.org/show_bug.cgi?id=680801
Implement the background-size CSS property, specified by the CSS
Backgrounds and Borders Module Level 3, including the keywords
"contain", "cover", and fixed-size backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=633462
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
The original support for CSS based shadows has been extended with
support for an optional spread radius and the 'inset' keyword,
so with the additional complexity a dedicated test case looks
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=642334
Currently, "-st-shadow" can mean one of three very
different things:
1) shadow based on alpha of the background image
2) shadow the "border box" of the node
3) shadow applied to the content of a StIcon
It isn't well defined which of the above 3 cases
-st-shadow will mean for any given node, however.
This commit splits the property into three
different properties, "box-shadow",
"-st-background-image-shadow", and "icon-shadow"
to make it all very explicit.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
This commit adds a few more examples to borders.js
that render borders with various combinations of
gradients, background images, shadows, and
border-images.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
In both tests the scrolled actor's width was fixed to the stage
width, so that the scroll bars ended up outside the visible area.
Fix by adding an outer container with a fixed width and expanding
the scroll view to fill the available area.
While non-uniform border widths were parsed correctly, an arbitrary
side's width was picked when painting, so that each border ended up
with the same width and the widths specified in CSS were ignored.
At least for sides between non-rounded corners, using a different
border width can be reasonable, for instance at screen edges.
Different border widths around rounded corners are kind of crack,
but then it would be lame not to support it ...
https://bugzilla.gnome.org/show_bug.cgi?id=607500
put a border around the "16px icon in 48px icon widget" test, to
verify that the icon is being centered correctly
add spacing and fix alignment for general prettiness
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Use st_texture_cache_load_icon_name_for_theme() so that we get the
right colors for symbolic icons. The code refactoring to achieve this
also avoids constantly starting a new icon load each time we set
a property on initialization ... the icon is loaded only after we
have a #StThemeNode assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Make StIcon compile and work in St.
Changes:
* ::icon-type and st_icon_set_icon_type are added to allow
specifying SYMBOLIC/FULLCOLOR for an icon.
* Ability to set the icon name from the theme is removed; it
wouldn't easily fit into our framework and two levels of
abstraction between code and image doesn't seem that useful.
* size CSS property is renamed from x-st-icon-size to icon-size
to correspond to what we are doing elsewhere.
* CSS and property based icon sizing are cleanly layered - if
you set the icon-size property, the CSS size is ignored.
* Add a simple JS test of StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Non-uniform border-radii are already supported when using a gradient
background, this patch adds support for solid colors as well.
The currently applied technique of using corner textures and filling
the remaining area with rectangles is extended, so that each corner is
padded with rectangles to the size of the largest corner.
Add border-radius.js to test cases, to test non-uniform border-radii
with both solid color and gradient backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=631091
StScrollable: Document how size negotation now works between the
parent and scrollable child.
StBoxLayout: Adapt to the new contract for how size negotiation
works; in particular, handle being allocated less than the
minimum size when scrolled and treat the minimum size as the
size of the scrolled area in instead of the natural size.
StScrollView: Substantially rewrite with fixes including:
- Implement new size negotation contract; this allows us
to determine scrollbar visibility without having to
connect to the adjustment.
- Implement all ALWAYS along with the existing NEVER/AUTO
- When hiding and showing scrollbars and shadows, don't
hide and show widgets, just turn on and off including them
in pick and paint. This avoids queueing relayouts.
- Cleanups for the code for connecting to adjustments,
for changing policy, and for turning on and off shadows.
scroll-view-sizing.js: New test case for StScrollView, allowing
resizing the scroll view interactively, changing the scrollbar
policies and turning shadows on and off.
https://bugzilla.gnome.org/show_bug.cgi?id=611740
The type we don't currently handle is _ALWAYS, my original use
of g_return_if_fail was wrong.
Also the default should be AUTOMATIC in the properties, not ALWAYS.
Finally the test case was still using the incorrect St.ScrollPolicy.
https://bugzilla.gnome.org/show_bug.cgi?id=609015
Previously we were hacking out the vertical scrollbar, this patch
allow us to sanely say in which directions we want to scroll.
Note this patch intentionally changes St to depend on GTK+ in the
API. I believe this is a correct long term change where we should
view St as co-evolving with GTK+ rather than replacing or paralleling.
https://bugzilla.gnome.org/show_bug.cgi?id=609015
Add StIMText, which is a drop-in replacement for ClutterIMText but
uses GtkIMContext instead of ClutterIMContext.
StIMText doesn't have preedit support (would need ClutterText
changes), so isn't going to be useful for complicated input methods,
but is good enough to get dead keys and similar working.
entry.js: Simple test case of StEntry
gnome-shell.modules: Remove clutter-imcontext module
https://bugzilla.gnome.org/show_bug.cgi?id=597471
Miscellaneous fixes from review:
- Distribute calendar.js and the interactive test
- Make the pointless protection against leap seconds actually work
by starting in the middle of the day so that forward/back always
move a day.
- Use a variable instead of an inline '8' to know where to start
when removing old day actors.
- Remove a stray comment from the test
https://bugzilla.gnome.org/show_bug.cgi?id=596432
js/ui/calendar.js: Generic calendar widget
tests/interactive/calendar.js: Basic test of the calendar
js/ui/panel.js: Add a pop-down from the clock that shows a
calendar widget. The pop-down is not menu-like to allow the user to
interact with an application while looking at the calendar.
gnome-shell.css: Add theming for calendar, calendar popup, and for
buttons on the panel
https://bugzilla.gnome.org/show_bug.cgi?id=596432
StButton is used for many things - scrollbar steppers, etc. Theming
all buttons to look like push-buttons breaks that. So in testcommon.css
just theme a .push-button class to look vaguely button-like.
https://bugzilla.gnome.org/show_bug.cgi?id=596432
Convert the StTable code from StStylable to StThemeNode. The
:row-spacing and :col-spacing GObject properties are converted
into spacing-rows and spacing-columns style properties.
A new interactive test is added for StTable.
https://bugzilla.gnome.org/show_bug.cgi?id=596811
Remove the StBoxLayout:spacing GObject property, and instead make
BoxLayout look up the spacing from the CSS style. This makes it
consistent with padding and will allow the use of units. (The
removal of the GObject property entirely instead of making it an
override is consistent with how we handle color, font, padding, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=596803
StBoxLayout: Make consistent that the area scrolled and clipped
to is the content area (excluding borders and padding.) Translate
back appropriately when chaining up so that the parent background
is drawn at the right place and picking on the box (if it's reactive)
picks at the right place on the screen.
clip-to-allocation is removed from StScrollView since it's just
not right - if the child has any non-moving elements, like headers or
borders, it will need to set a narrower clip. And even if the entire
child scrolls, we want to clip to an arrow that excludes the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=595997
When a StBoxLayout is allocated a size less than its natural size,
think "shrink" needs to be divided among the children that have
a smaller minimum size than natural size.
This is done by preferentially shrinking the children that are most
expanded from their minimum size and then increasing that set of
children until we've found enough total shrink.
A new method is used of allocating children at integral sizes - instead
of rounding the per-child extra amount to an integer (which causes
cumulative round-off errors), compute the position as we go along in
floats and round individually for each child widget.
Extend the box-layout test to include of a test of a box being set
to various widths, starting quite narrow.
http://bugzilla.moblin.org/show_bug.cgi?id=6311https://bugzilla.gnome.org/show_bug.cgi?id=595995
