First of all, that call is deprecated. Second, we don't have RC styles
anymore. Third, what that function does today is invalidate style
contexts, but that happens automatically when setting the screen on the
style context later.
So this function is completely unnecessary.
Don't just create a menushell and populate it with random data -- verify that
the resulting menu layout is actually correct.
This is introduced in a separate commit because the old code was failing this
part of the test.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
The following CSS would infloop:
@define-color self @self
as it would infinitely lookup the color named "self" and try to resolve
it. This patch adds detection of such cycles to the resolve function by
keeping a list of currently resolving colors in the cycle_list variable.
If a named color references a nonexistant named color, we didn't catch
that error and ended up crashing on a NULL-dereference.
This crashed Boxes, because its CSS referenced values from the theme
that didn't exist in any theme.
We were calling gtk_overlay_child_allocate() both in realize
and in add as we wanted to create and position the child windows
for the widgets. However, this call also actually called
gtk_widget_size_allocate() on the child, which it shouldn't. In some
cases the overlay is realized before being allocated, and thus it
will allocate the child at 0x0 which is an invalid size for it to be in.
In particular, if the child has margins set this will result in negative
allocations and warnings.
This fix splits out the allocation computation so that
gtk_overlay_create_child_window can use it without callers
having to call gtk_overlay_child_allocate() to move the windows.
https://bugzilla.gnome.org/show_bug.cgi?id=696623
When no GDK backend can be initialized (either because
GDK_BACKEND has been set to the wrong value, or the backends
are simply not included), the expectation is that gtk_init_check
should return FALSE, not error out.
This commit makes it so, by using gdk_display_manager_peek
instead of gdk_display_manager_get in code paths that are used
during initialization.
This is an (unintentional) side effect of my changes to GtkTreeView's
get_preferred_size() implementation. It seems odd to me that
GtkTreeView directly determines its own size when inside a
GtkScrolledWindow, but since it does, it should be using its natural
size, not its minimum size.
This make the nice 'snap off' feature of gnome-shell work
with client-side decorations. weston moves the maximized window
around, which is less ideal...
We already set it in init, so this is just redundant.
The additional window-content style class here is needed so that we can
distinguish between the full X window background and the background for
the actual window contents.
Prevent the new window dragging code from interfering with
selection of colors on button release, by handling button
presses we care about instead of letting them bubble up to
the window.
Partial fix for
https://bugzilla.gnome.org/show_bug.cgi?id=695493
We were not translating event coordinates to the toplevel
window, thus the regions we determined were not right.
We were also not respecting the maximized state, and we
were unnecessarily refusing to handle events when not decorated.
https://bugzilla.gnome.org/show_bug.cgi?id=696197
If the style changes before we're realized we will delay the
style-updated signal until realize. However, we then lose
the changes bitmap. This means that gtk_widget_real_style_updated()
must treat a NULL change as "everything changed" and queue a resize.
The code was always adding a label widget as a child, but
then skipping over it in forall if a custom_title was present.
This confuses internal logic of GTK+ which assumes that it
can iterate over the entire widget hierarchy with forall,
to maintain state. Fix this by destroying the label when
a custom_title is set, and recreating it as needed.
The function update_window_buttons shows or hides the title header after it
has finished updating the visibility of the various buttons. Unfortunately
this
conflicted with the hiding of the title done when going fullscreen.
This solves the problem and fixes the rendering of fullscreen applications by
using update_window_buttons to control the visibility of the box in the
fullscreen case.
This reverts commit 30a1a79322.
This turns out to be unnecessary when you can set the titlebar
on the window and let GtkWindow handle the events. As a benefit,
we get the window menu on custom titlebars for free.
A new function that sets a custom titlebar on a GtkWindow.
With client-side decorations, the custom titlebar simply
replaces the one that GtkWindow would otherwise create itself.
With traditional decorations, we tell the window manager
to just decorate the window with a border. This works ok
at least with metacity and mutter.
For csd, we were subtracting the border width one too many
times from the child height, causing clipped off content e.g.
in the 'Properties' window in testgtk.
To clear the tooltip one is to set the tooltip to NULL. Though
the GtkEntryAccessible expect this tooltip to not be NULL in
gtk_entry_accessible_notify_gtk (already handling this case
in its _init).
Fixes:
** (epiphany:23914): CRITICAL **: atk_object_set_description: assertion
`description != NULL' failed
when epiphany g_object_set the entry icon tooltip to NULL (clear the
tooltip) in its find bar.
https://bugzilla.gnome.org/show_bug.cgi?id=695375
To extract the mnemonic key value, the string must contain the
underscore. But when the "gtk-auto-mnemonics" setting is true and when
the Alt key is not pressed, the underscore must not be displayed. The
problem was that the 'new_str' variable was used for both purposes:
extract the text to display, and extract the accelerator character.
When the underscore must not be visible, the underscores were removed
from the 'new_str' variable before extracting the accelerator character.
Now there are two strings, one for each purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=674759
For now, nothing changes, we're using the sum of inner and
outer border everywhere.
In the future, we will make the inner border the visible
window frame, and the outer border the shadow/resize border.
Add a style property to control the presence and order of
window buttons. We allow buttons at the left and right side,
they can be specified like this: icon,close:minimize,maximize.
Also, change the default button layout back to have just a close
button on the right, use icons in buttons, and set style classes
on the buttons, to allow better theming.
Add window-minimize, window-maximize, window-restore and window-delete
icons to the builtin icon theme. These will be used for icons in
the window buttons, and the expectation is that the icon theme
will provide icons matching the desired decoration style.
window-delete is used instead of window-close, since window-close
is also used for GTK_STOCK_CLOSE, and the two may require different
styles when used inside the application vs in the window frame.
Hide the close button if the window is not deletable, hide the
maximize button if the window is not resizable, and hide all
buttons if the window is a dialog.
Update buttons when the window state changes.
Client side decorations can be enabled on non-Wayland platforms by
setting the GTK_CSD="1" environment variable.
We must ensure we have a GdkVisual that has an alpha channel since
the decorations rely on transparency. If we cannot get a visual with
an alpha channel then we do not enable client side decorations.
Otherwise we'll potentially get some background sticking through our rounded
corners in our decorations. The actual background will get drawn as part of
the decoration drawing.
This change comprises four main parts:
* the creation of the widgets that form the decorations,
* implementation of get_preferred_height/width, and the for_width/for_height
variants,
* taking the decorations into account when allocating,
* and drawing the decorations themselves.
Kristian did the bulk of the original work on this but any bugs are almost
certainly mine through the many refactorings and rebasings.
Update the documentation and users of this function to handle
the future case that that we have some internal decorations to the window and
useable allocation is thus smaller.
By having a separate out parameter there is no need to have an in/out function
and allows for greater robustness.
The current implementation simply returns the allocation provided.
For gtk_text_iter_get_char(), due to the "Returns" at the beginning of
the description, the description was not visible. So the first sentence
has been reworded.
If there are rows that contain only spanning children,
our algorithm was unnecessarily distributing extra space
to the other rows, even if they contain only non-expanding
children.
We improve the behaviour by treating rows containing only
spanning children as expanding.
... instead of taking the last one we find. This is necessary as
attached widgets (mostly menus) can be attached to an invisible widget,
but we still want to invalidate styles for them.
https://bugzilla.gnome.org/show_bug.cgi?id=695772
When setting new text on the label, the text-changed::delete signal
needs to be emitted before deleting the text (so that atk-bridge can
query the old text) while the text-changed::insert event needs to happen
afterwards (for the same reason). The old code using the notify signal
was only emitted after changing the text.
Both of them started to make use of round(), a C99 function. So, include
fallback-c89.c to provide a fallback implementation for round() for
compilers that don't have round()
https://bugzilla.gnome.org/show_bug.cgi?id=694339
Change of plans to match the tests from the previous commit.
The state of the underlying dialog is never reflected by GtkFileChooserButton's API,
as the dialog is a transient thing. The file chooser button only updates its state from the dialog,
and reflects the dialog's state, when the dialog has been confirmed and dismissed by the user.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We used to have numeric names, which are a pain to maintain when new tests are added.
Now we have a real nomenclature (see the comment at the beginning of the open-dialog-cancel-* tests),
which lets us see easily if we have tested all the combinations.
Also, added all the combinations that were missing and removed redundant tests.
Not all the tests pass currently.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The idea is that the button will only update its state of the selection and current folder
when changes to those are done either by the calling program (with the filechooser's API)
or when the user actually confirms and dismisses the underlying GtkFileChooserDialog.
If the user makes changes to the dialog but has not dismissed it yet, those changes
will not be reflected in the button (as one would expect).
This commit also makes sure the current-folder-changed and selection-changed signals
are emitted at the right times.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emitted that signal when the selection changed through the underlying GtkFileChooserDialog.
To do this when the dialog is not active and the selection is changed by the calling program
(instead of by the user), we need to wait until the GtkFileChooserButton's UI has been updated
via an async callback from GIO. So, we keep track of whether an entry point into the
button's API caused a programmatic change in the selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This should let tests complete faster. Also, this will let us test
that the correct signals are actually being emitted.
The tests now fail, as the signals are not being emitted when they
should.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only FORCE_INVALIDATE when something weird changes that the CSS
machinery can't detect. But now that our style_updated functions skip
recomputations when some properties don't change we want to make sure
these recomputations are still run. So we just claim all properties
changed.
http://bugzilla.gnome.org/show_bug.cgi?id=695482
And also explicitly remove pointer/keyboard grabs from the display.
Whenever the grab is reported lost, we should popdown the combobox, so that the
GDK_WINDOW_TEMP window is hidden and removed from the toplevel, as done with
the menu for example.
Leaving the GDK_WINDOW_TEMP window open when re-activating the application
triggers several issues in the win32 backend, due to restacking windows of the
non-toplevel group into the toplevel group:
https://bugzilla.gnome.org/show_bug.cgi?id=695200
Something is causing the GtkFileChooserDialog to be resized really small on the second time it is run
during each test for GtkFileChooserButton. So as a temporary hack we set it to 500x500 pixels on
the second run, so the size allocation code doesn't bomb on us.
The currently-selected file *is* the selection even in SELECT_FOLDER mode. Do not confuse this
with the current folder.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
gtk_tree_view_column_unset_tree_view() resets column->priv->tree_view to
NULL.
The function is called when a column is removed, but later from the same
function we would call _gtk_tree_view_column_unrealize_button(), which
expects column->priv->tree_view to be != NULL, causing these critical
warnings
Gtk-CRITICAL **: gtk_widget_unregister_window: assertion
`GTK_IS_WIDGET (widget)' failed
This commit moves the call to unset the tree view after the button is
unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=695473
We assumed that we didn't have to update the combo box if the dialog got cancelled,
as it should simply retain its previous contents. But this assumption doesn't work
as the dialog is brought up with the 'Other...' item - we don't want the
combo box to keep showing 'Other...' if the dialog is cancelled.
The test from the previous commit now passes.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There is this bug:
1. Start with a file chooser button in SELECT_FOLDER mode, and select a folder from the combo box.
2. Click on the button's combo box, select 'Other...'
3. You get the file chooser dialog. Cancel the dialog.
4. The file chooser button's combo box still shows 'Other...' instead of
showing the selection from (1).
This is a test to ensure that the original selection is restored.
The test fails right now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is surprisingly tricky, since the (None) item *has* to be a visible item while
the combo box is *not* popped up, so that it can show its contents. But the item
has to be *not* visible when the combo box is popped up.
Also, update the whole button's selection, not just the underlying dialog's, when
the combo box changes its selection - based on a patch by Paul Davis in
https://bugzilla.gnome.org/show_bug.cgi?id=691040#c20
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way the internal labels will show the correct selection even if nothing
has been selected programmatically.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We didn't change it when the file chooser button's dialog was inactive, and so
the actual file chooser button would not visually reflect the current selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We do some gymnastics to pull the string out of the GtkButton or the GtkComboBox that is
being used in GtkFileChooserButton to show the current selection when the dialog
is inactive - namely, we look for the subwidget with the correct ATK role, and pull its
accessible name.
Currently the test fails; this is https://bugzilla.gnome.org/show_bug.cgi?id=691040#c18
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
In the case of checking for local_only, g_file_is_native() is not useful, since it
will return FALSE for something in a FUSE mount.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since FUSE locations can be handled safely by applications show these mounted locations regardless of whether gtk_file_chooser_set_local_only()
is set to TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=586367
We do this by making the ::populate-popup signals a little more
flexible. They used to just accept a GtkMenu as argument, now
they can take a menu or a toolbar. To not break the expectations
of existing callbacks, we only emit ::populate-popup with a toolbar
if the :populate-toolbar property is TRUE.
Now, even if the handles being rendered are small, the handle touch
input shape will be as wide as the visible part of the rendered asset, and
high enough to cover both the handle and the height of the line where
the selection bound is.
Also, make handles have the same virtual distance to the line top/bottom
when a drag starts, so the handle doesn't jump to another line after a
too short threshold.
Don't set handles mode to none if the event has send_event set.
For consistency with GtkEntry, also make GtkTextView keep the
handle mode on buffer changes.
We block signal handlers areound GtkEntry signal emission and if those
signals get used to call functions on the completion that cause a
reconnection of the signals, then the reconnected signals will not be
blocked anymore (so they might get emitted?) and unblocking the old
signal id will later cause warnings.
Fixes spurious warnings in gtk/tests/filechooser tests.
When setting contents of the clipboard and ownership or user data changes, we
end up calling clipboard_unset() to fully cleanup the previous clipboard state.
This call will itself call clear_func() for the previous user_data, and always
reset both 'get_func' and 'clear_func' to NULL.
So it's actually not possible to have 'get_func' being non-NULL once we have
called clipboard_unset(), so just remove that condition check and the code
inside.
https://bugzilla.gnome.org/show_bug.cgi?id=694924
icon_info_dup() is now called also for GtkIconInfos that already have
a pixbuf, so we must make sure that we correctly carry that from
the original icon_info to the copy.
This is checked by GIO for us now.
Also, it's generally just a bad idea spawning error dialogs from inside
a library on top of other dialogs: lesson learned.
https://bugzilla.gnome.org/show_bug.cgi?id=675333
If you tried to lookup an icon that was not emblemed, and then looked up
an emblemed icon with the same base, we would override the iconinfo adding
the emblems inline. Later, when the icon finished rendering, inside
gtk_icon_info_load_icon_finish, we would copy the result from the duplicate
(which did not include the emblem infos), but the icon would still fail the
assertion, because emblems infos are present but emblem_applied is false
(they were not requested in the first place!).
Solve this by avoiding the overwrite on a cached iconinfo, and instead duplicate
the iconinfo before adding the emblems. It is expected that another layer
of caching (such as StTextureCache in gnome-shell) will take care of avoiding
multiple rendering of the same icon+emblem combination.
https://bugzilla.gnome.org/show_bug.cgi?id=694968
Instead of using the secondary slot for both clear and search. This
Makes it possible to use the search icon for actions regardless of
whether text has been entered, makes it possible to use the primary
icon to indicate search status, allows us to indicate the purpose
of the entry even if text has been already entered.
https://bugzilla.gnome.org/show_bug.cgi?id=694990
The last change fixed the windowed widget case but broke
opacity group handling for windowed child widgets. This fixes
up the code by making sure we norender_children in when there
is an opacity group.
This also cleans up the comments about how this works to something
that is hopefully more understandable.
We always need to render the background, as the window
background is not always set (i.e. during gtk_widget_draw()) or
when its partially visible.
https://bugzilla.gnome.org/show_bug.cgi?id=694925
Mutter magically ignores override-redirect windows with geometry
-100-100+1+1, and this breaks the frame synchronization between
gtk+ and mutter. For now, we avoid the issue by simply giving
the window a different geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=694217
When the range of the GtkRange is zero (i.e. the upper and lower bounds
of the adjustment have the same value), don't use an origin to draw the
trough, as the slider will also be hidden, and the juncture between the
two sections of the trough will be visible.
It's not friendly to bindings, and we didn't need an inout parameter anyway.
We use a simple return value from the signal handler now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The default CSS didn't have anything for GtkTreeView's 'dnd' style class. So,
the call to gtk_render_frame() to draw the highlight frame for the drag-dest-row
was getting a border-width of 0, and nothing was drawn as a result.
Now we just copy the default from Adwaita, but make the border-radius 0, to make it
square like the rest of the Raleigh theme...
Unmounted volumes don't have a URI yet, so we can use that to distinguish them
from within the DnD code.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The file chooser button only supports single-selection modes, so
switch the code to a simpler gtk_file_chooser_get_file() to avoid
dealing with GSLists of a single file.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Update the Visual Studio projects for gtka11y and the completion of the
projects that go along with it. This have been distcheck'ed on my Ubuntu
12.04 system.
This may ensure that the dialog is actually done initializing. We need to kill this
sleeping business and really use signals, sigh...
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emit that signal when the user confirms the button's internal GtkFileChooserDialog,
or when he drags-and-drops stuff into the button.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This ensures that data maintained by the button while the dialog opens/closes remains consistent.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Previously we could end up in a situation where browse_list_model==NULL, and yet load_state==LOAD_FINISHED.
This is not a valid state. So, when we get rid of the list model, really ensure that we end up
in LOAD_EMPTY so nothing assumes that there is a valid list model around.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We don't want to emit state changes for all the cells in a row, just for
the cell in the expander column. It's the only one that reports EXPANDED
or EXPANDABLE states, after all.
Also, contains refactoring of the affected functions for all the special
cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694059
We weren't checking the removed flag but the added flag for removal
emissions, so what would happen for every state change notification was:
- on state-added, both an "added" and a "removed" event were emitted
- on state-removed, nothing
https://bugzilla.gnome.org/show_bug.cgi?id=694059
The callback function gtk_window_on_theme_variant_changed is only used on the
X11 backend (where GtkSettings is used for the settings information.)
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=674207
We can't safely examine allocations synchronously using
gtk_main_iteration(), as there might be not enough time for a new paint
clock tick to have expired and the allocation set on the widget.
Work this around adding g_usleep() calls before processing pending
mainloop events.
With the following code:
#define INVALID_CHAR GDK_KEY_VoidSymbol - 1
gtk_accelerator_get_label (INVALID_CHAR, GDK_SHIFT_MASK | GDK_CONTROL_MASK);
we would get this label:
Shift+Ctrl+
instead of this label:
Shift+Ctrl
https://bugzilla.gnome.org/show_bug.cgi?id=694075
Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
We only draw the main entry on should_draw (widget->window), because
otherwise we also draw it on the GtkTextHandle widgets.
This is necessary due to the recent change for that to not return
TRUE and swallow the rest of the drawing operation.
This was causing warnings on widget unparent like:
Gdk-CRITICAL **: gdk_window_has_native: assertion `GDK_IS_WINDOW (window)' failed
Becasue the window was not properly removed from the lists on unrealize.
We clear GtkTickCallbackInfo on creation to ensure all fields start
as 0. Before we sometimes ended up with destroyed being 1
so the tick was never called.
gtk_icon_info_copy and gtk_icon_info_free are deprecated for
the corresponding GObject methods.
We set correct transfer markup for the GtkIconInfo returning methods
to fix the introspection of them.
gtk_icon_info_load_symbolic_for_context_async had the wrong method
name in its documentation block.
We need to disconnect the frame clock when we unrealize (at which
point the old clock is still alive) not in destroy(). Since there
is no common unrealize for containers, trigger this from GtkWidget.
Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.
Remove:
- GtkTimeline. The consensus is that it is too complex.
- GdkPaintClockTarget. In the rare cases where tick callbacks
aren't sufficient, it's possible to track the
paint clock with ::realize/::unrealize/::hierarchy-changed.
GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
When we have a looping animation for something like an angle,
we need to make sure that the distance we go past 1.0 becomes
the starting distance for the next frame. This prevents a
stutter at the loop position.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Use GdkFrameClock for the timing of GtkTimeline. This require the
user to provide either a GtkWidget or a GdkFrameClock when creating
the timeline. The default constructor now takes a GtkWidget. If you
want to create a GdkFrameClock without a widget, you need to use
g_object_new() and pass in a GdkFrameClock and GdkScreen.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
The frames-per-second for an animation should be controlled by how
fast we can process frames and the the frame-rate of the display; it's not
a meaningful app-settable property.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Add back the GtkTimeline code that previously made private and
then removed. It will be hooked up to GdkFrameClock. This commit
purely adds the old code back.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Switch GtkStyleContext to using GdkFrameClock. To do this, add a new
UPDATE phase to GdkFrameClock.
Add a GdkFrameClockTarget interface with a single set_clock() method,
and use this to deal with the fact that GtkWidget only has a frame
clock when realized.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Instead of having gdk_frame_clock_request_frame() have
gdk_frame_clock_request_phase() where we can say what phase we need.
This allows us to know if we get a frame-request during layout whether
it's just a request for drawing from the layout, or whether another
layout phase is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
This is necessary in order to have async operations on it.
All the old copy/free functions keeps working, and g_boxed_copy on a GObject
also works, so this should be mostly compatible, but techncally its a minor
ABI break since the GType changes fundamental type. Changes like this has
happened before though, like with GVariant becomming its own fundamental
type.
https://bugzilla.gnome.org/show_bug.cgi?id=693802
These are generic tests that can test the button in all of its modes,
instead of hand-written tests for each combination.
Some tests fail currently.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
