Commit cfecd063c9 changed the allocation logic to not allocate
scrollbars when the *_visible booleans are false. This breaks the
fade effect as well as the NEVER policy. We do not paint scrollbars
when they are not supposed to be visible, so not allocating them
and thus leaving them in a "needs allocation" state just causes problems.
I am not convinced that it solved any problem to begin with (we don't paint
them anyway).
As the previous condition has basically always been true, just do it
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=705664
We don't set :visible on the scrollbars, but use booleans to track
if they are visible. Thus check the booleans instead of the actor's
properties when allocating the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=704265
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
The code here before was added as dummy code to satisfy an error
in the missing switch, and wasn't ever tested due to the lack of XI2
in mutter. Use the same math as GtkRange does to calculate scroll bar
positions from raw XI2 deltas to allow for proper smooth scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
Currently the scroll event code only handles scroll events if the
adjustment's value is within the "lower" and "upper" limits. The
likely intent was to pass events to a parent scroll view when
reaching the bounds (uh, nested scroll views!), but apparently
we never made use of this, as the upper bound is actually wrong
(an adjustment's maximum value is upper - page_size, not upper).
Just handle all scroll events unconditionally and rely on the
bound checks in StAdjustment.
https://bugzilla.gnome.org/show_bug.cgi?id=672413
Currently compilation fails with -Werror, as we don't handle the
(newly introduced) smooth scroll events in switch statements; add
some basic support, which should make the compiler happy.
https://bugzilla.gnome.org/show_bug.cgi?id=672413
This assignment was shadowed by the giant switch above. Since the
switch has a comment or two explaining the logic inside of it,
keep that instead of the assignment.
Since an StWidget now has children, it needs to allocate those children
properly. Defer to the currently installed layout manager, like Clutter
does.
Now that we have something that allocates children in St, to prevent
double allocations, we use clutter_actor_set_allocation rather than
chaining up to StWidget::allocate.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Since we want to paint children by default in StWidget, we need to
provide a way for custom subclasses to paint their CSS backgrounds
without painting children... introducing st_widget_paint_background.
Additionally, remove any custom paint/pick handlers added by subclasses
of StWidget that just painted their children. This will cause double
painting if left alone.
This also removes the hacky things that some subclasses of StBin did
to prevent their one child to be painted by StBin.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
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
Add Ctrl-Alt-Tab support to ViewTab, and fix the Applications pane to
scroll to track the keyboard focus.
The Windows pane can be switched to, but navigation within the pane is
not yet implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
In RTL locales, the vertical scrollbar should be located on the
left, so take the widget's text direction into account when
allocating the view's elements.
https://bugzilla.gnome.org/show_bug.cgi?id=643156
* Make sure all source files have a LGPL copyright header, and standardize
non-standard variations of the header to a common form.
* Check and update all copyright notices.
* Remove 'Written By:' lines. They are universally incomplete and
typically indicate only who started a particular file.
https://bugzilla.gnome.org/show_bug.cgi?id=634550
We weren't properly nulling out the vadjustment variable in dispose()
which meant in the case of explicit-destroy followed some time later
by garbage collection and disposing the actor again we would crash.
The relationship between adjustments and scrollbars and
scrollable widgets was much more complex than it needed to be.
StScrollView: Have the scroll view own a pair of adjustments,
set them on the child on add(), remove unnecessary
change notification signal connections.
StBoxLayout: Remove auto-create of adjustments, just take the
adjustments from the scrollbars and set them on the scrollable
child. Notify for hadjustment/vadjustment properties.
StScrollBar: Notify adjustment property.
StScrollable: Document how adjustment setting works.
https://bugzilla.gnome.org/show_bug.cgi?id=611740
StScrollable: Document how to set adjustments
StBoxLayout: Make sure that we always have upper >= lower + page_size,
so that clamping works properly. Set the page_increment to be slightly
less than the page_size so there is some overlap, as is customary.
StScrollView: Remove unnecessary fabs() calls, rewrite expressions
for additional clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=611740
- Fix existing typos and spacing problems
- Get preferred height, not current height, of shadows
- Let shadows overflow don't clamp them when we have too little space
- Remove a now-unecessary stray MAX()
- Fix up scrollview visibility for the pathological case of no child
- Disconnect from adjustments on remove()
- Don't unset the adjustments on the child on remove(), since they
already existed or were autocreated on add()
(We should what we are doing and set the adjustments of the
scrollbars on the child rather than setting the adjustments of
the child, so we match GTK+'s scrolllable interface, but this
at least makes it consistent instead of a weird mix.)
https://bugzilla.gnome.org/show_bug.cgi?id=611740
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
StScrollBar: Be robust against being disposed multiple times,
which can happen, and in fact, normally happens when destroying
the parent.
StScrollView: Implement remove() for the hscroll and vscroll members,
and just destroy them in dispose() and let them be removed.
unparent the shadows, instead of just unref'ing them directly.
https://bugzilla.gnome.org/show_bug.cgi?id=611203
Add a 'vshadow' property to StScrollView, which, when turned on,
overlays gradient shadows on the top and bottom of the StScrollView.
Turn this on for the StScrollView used for the app browser.
https://bugzilla.gnome.org/show_bug.cgi?id=609604
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
ClutterGroup calls _destroy, but most of St was just calling _unparent.
This caused problems because the DESTROY signal was not emitted
for child elements after destroying a toplevel. Also, in a GC'd
binding it would cause unpredictable lifetime of children.
Some St widgets simply didn't have _dispose at all; implement it.
Note because of the usage of the background_image in StButton,
we can't cleanly destroy it inside the StWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=597845
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
Rather than repeating the computation of borders in many different
widget subclasses, add helper functions:
st_theme_node_adjust_for_height()
st_theme_node_adjust_preferred_width()
st_theme_node_adjust_for_width()
st_theme_node_adjust_preferred_height()
st_theme_node_get_content_box()
That are used in get_preferred_width()/get_preferred_height() and
allocate() methods to consistently apply the necessary adjustments.
This allows removing the StPadding type.
Queueing a relayout when the borders/padding change is moved from
st_widget_real_style_changed() to the invoking code to allow access
to the old StThemeNode for comparison. (Should this be added as
a parameter to the signal?)
Borders are included in the geometry adjustments, but borders
are not yet drawn.
https://bugzilla.gnome.org/show_bug.cgi?id=595993
ShellTheme replaces both StStyle and ccss_stylesheet_t.
The interface StStylable is replaced by usage of ShellThemeNode.
A concrete node class allows some significant optimizations of property
inheritance that would have been much more difficult to achieve with
the highly abstract pair of StStylable and ccss_node_t.
Some operations that were previously on StStylable (like the
::style-changed signal) are directly on NtkWidget.
Custom properties are no longer registered as param-specs; instead you
call directly into shell theme node to look up a length or color:
shell_theme_node_get_length (theme_node, "border-spacing", FALSE, &spacing);
The dependency on libccss is dropped, while preserving all existing
functionality and adding proper parsing and inheritance of font properties
and proper inheritance for the 'color' property.
Some more javascript tests for CSS functionality are added; workarounds for
a CSS bug where *.some-class was needed instead of .some-class are removed.
https://bugzilla.gnome.org/show_bug.cgi?id=595990
To each .c and .h file, add:
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
'gnu' is the default anyways for Emacs, but indent-tabs-mode is not,
so this sets things up to correspond to the policy of no-tabs.
http://bugzilla.moblin.org/show_bug.cgi?id=6467
Add GObject Introspection annotations to methods where needed, in
particular adding (transfer none) to return values that don't transfer
ownership.
st_texture_cache_get_actor() and st_texture_cache_get_texture()
are annotated as (transfer none) since they return a newly
created *floating* texture.
https://bugzilla.gnome.org/show_bug.cgi?id=591245
