This removes a horrible workaround for bug 126797. To prevent
picking up accidental markup in label texts, the label accessible
is listening for window creation and mapping and defers initializing
its text until then.
A first experimental conversion from the gail namespace to gtkaccessible.
At the same time, use gtk_widget_class_set_accessible_type() to register
the accessible type for GtkLabel.
Avoid many unnecessary list iterations by using a hash table
to store cell infos, and caching row and column counts. Based
on patches by William Jon McCann, bug 554171.
tree-performance results:
before: (MINPERF:large tree test with a11y: 9.18531sec)
after: (MINPERF:large tree test with a11y: 0.923463sec)
for comparison, without accessibility:
(MINPERF:large tree test: 0.016179sec)
As set_description is never called and unsupported by the at-spi, we can
omit implementing it.
This means we can also omit get_description calls in various places, as
they'd just return the default value: NULL.
This code was supposed to work around a bad interaction between GOK and
Nautilus from 7 years ago.
If it still exists, the GOK developers may complain to the Nautilus
developers.
https://bugzilla.gnome.org/show_bug.cgi?id=137401
It turns out that ATK_DEFINE_TYPE_WITH_CODE() is broken; it
tells GType that the class and instance size for the accessible
type are the same as for its parent type. Which is not true
if your instance struct has members such as 'description' here.
This was causing hard-to-track-down memory corruption, since
description and the GtkAccessible private pointer were sharing
the same memory location.
The function is supposed to bypass the ATK registry. For 2 reasons:
1) We get rid of a lot of boilerplate madness.
2) The registry allows creating multiple accessibles per widget and we
don't.
The old code for registries is still there.
It is now no longer possible to disable it.
This doesn't matter though because GTK will not instantiate a11y
objects until you actually use it. So nothing changes in practice.
Basically, don't ever set the current folder, and only use
gtk_file_chooser_set_filename() for 'File/Save As'. This is so
that the file chooser will be able to present its recently-used
lists as appropriate, giving the user good suggestions by default.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
None of the cases where _gtk_file_chooser_entry_set_base_folder() appear to require
the entry highlighting the file's basename. Doing the highlighting actually makes
things look weird in Save/Recent mode if you
1. type a filename
2. click on a recent-folder,
as right after (2) your filename would get its basename highlighted for
no apparent reason.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The create-folder machinery doesn't handle that case yet; we may enable it later
once we figure out the implications for the GUI.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to be that every part of the file chooser's code would show/hide the widgets
near the pathbar as needed. Now we have two central functions:
path_bar_update()
path_bar_set_mode()
These take care of all the widget shuffling; setting the visibility of the
pathbar, info bar, and Create Folder button as appropriate; setting the contents
of the info bar, etc. - based on the current operation_mode and action.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We will centralize the place where all the pathbar-related widgets are created:
the location button, the pathbar itself, the Create Folder button, and in
subsequent commits, the info bar as well. We will deal with the pathbar/infobar
as a unit, instead of swapping them in and out in an ad-hoc fashion.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since the GtkFileChooserEntry already gets the recent-folder set upon it when a recent-folder
is selected, it already can give us the correct fully-formed path.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us do proper completion in GtkFileChooserEntry even when no base folder
has been set. Completion for relative paths won't work, as usual, as expected.
They weren't being selected in the shortcuts bar when those modes were
activated programmatically, instead of through the user selecting
them from the user interface.
In RELOAD_EMPTY mode, when no folder has been selected by the calling app, we now
start showing the recently-used list. The rationale is as follows:
- In Open mode, the user is likely to pick a file he has used recently.
- In Save mode, the user is likely to want a destination folder which
he has used recently.
For the Save case, where we want to present the user with recent folders instead
of recent files, we will make the recent-list do so in subsequent commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Now we reparent the browse_path_bar_hbox to that spot in Save mode,
or to be above the file lists in Open mode. The pathbar makes for a very
clear indication of the location to save in.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
And with this we get rid of the craziness of having a separate filter model
for the combobox's model.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This effectively makes the file chooser always be in 'expanded' mode.
Later, we'll move the pathbar to the 'Save in folder:' line.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This extracts the parent folders from the items in the recently-used
list. We'll use it in the file chooser to present a list of
recently-used folders.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The table was incomplete and out of date. Instead, just
put a list of links in that place, and move all the extra
documentation to the macros. Bug 653785
When we build the sibling path for the order, we do not skip hidden
children (since, quoting the comment, "we cannot reliably detect changes
in widget visibility"). So we need to invalidate the order when hidden
children are reordered and removed.
https://bugzilla.gnome.org/show_bug.cgi?id=652769
Removing the window from the window list before setting the
application to %NULL avoids gtk_application_remove_window() triggering
another call to gtk_application_window_removed(), which would release
the application a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=653053
It turns out there's more places where the toolbar item size is used as
the margin box instead of the content box. Because of that, store the
margin box when allocating and use it whenever calls
toolbar_content_get_allocation() instead of calling
gtk_widget_get_allocation().
size_allocate() allocates the available space for the margin box,
get_allocation() returns the actual space of the content box and those
can be different. And then animations never stop.
If that makes you go "huh?", you might want to read
http://www.w3.org/TR/CSS21/box.html
and the docs for gtk_widget_compute_align().
... and implement the CSS font properties:
- font-size
- font-style
- font-family
- font-weight
- font-variant
This is the second try at this. The first was backed out previously due
to bugginess. Let's hope this one survives a bit longer.
Also makes the font-family CSS test work again.
At http://dev.laptop.org/ticket/10643 we are seeing that drag-and-drop
within the Sugar shell causes all of Sugar's custom keybindings to be
removed.
This is because gtkdnd tries to unbind XK_KP_Space, which (on my systems)
is resolved to NoSymbol by XKeycodeToKeysym(). NoSymbol has value 0,
the same as AnyKey, and XUngrabKey(AnyKey) is equivalent to unbinding
all possible keycodes.
Fix this by catching NoSymbol before binding/unbinding.
https://bugzilla.gnome.org/show_bug.cgi?id=652402
Use a bunch of tricks to get inset/outset right with a small amount of
code. In particular, fix the hidden sides causing artifacts.
Included is a bunch of code comments explaining what we actually do.
Now instead of invalidating when we create the layout we invalidate
when we realize the widget and we remove the invalidation when
unrealizing. It was pointless too destroying the layout in unrealize
as at the end what we just wanted was to remove the invalidation idles.
This is necessary because we want to use NULL as the default value. But
the default value for borders is { 0, 0, 0, 0 } and not NULL.
Fixes border-image-gradient and border-image-repeat reftests.
Stop documenting the base class as just a base class for the
H and V specializations, copying the useful descriptions from
those H/V classes to the base class. Do not advise the use of
the H/V classes or refer to them unnecessarily.
Now that we are not allocating treeview column buttons anymore
with invisible headers, we can't rely on their allocations for
other things like cell area computations anymore. Use x-offset
and width of the column directly, instead.
GtkDialog changes its size depending on style properties. If
we only do this in response to ::style-updated, it happens during
the initial realization of the dialog and leads to the dialog
'growing' between when we determine the initial window size and
when we allocate it that size. So, do this beforehand.
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.
It's a custom property with the same semantics of text-shadow, which
works on icons and icon-like UI elements, such as spinners, arrows and
separators.
It's an entry, so it already has a background below, even when the entry
doesn't have a frame. Also, gtk_spin_button_draw_arrow() will render a
background and a frame in the arrow space anyway.
NULL is a valid value for border-image, so if it's NULL when unpacking,
don't try to access the struct fields, but just init the GValues for the
unpacked parameters.
The new code is smaller, less crashy and correct(er), but arguably more
complex. I'd have liked to make it simpler, but this border image
algorithm is complex...
It's not useful to cache these surfaces here, as the GtkBorderImage will
be always generated on the fly, being a shorthand property.
This also allows to get rid of the intermediate image surfaces for
rendering the slices; we now use cairo_surface_create_for_rectangle()
to proxy the slices from the source surface to the rendered area, which
should also yield better performance.
It's composed by
- border-image-source: a cairo_pattern_t holding an image from file or a
gradient
- border-image-slice: a GtkBorder containing the slice offsets to apply
on the image
- border-image-repeat: a GtkRepeatType for the image
We deviate from pure CSS3 in the following ways:
* border-image-width is assumed to be always 1, i.e. always equal to
what's specified by border-width. I don't think it's a particularly
useful property to have, but we could add it later if needed.
* border-image-outset is absent, as we can't render outside of the
allocation yet.
https://bugzilla.gnome.org/show_bug.cgi?id=651194
It seems to be very broken wrt input handling, causing random icons to
light up etc.
So until this is fixed, better remove composite support. It only removes
animations, so it's not a big loss for functionality.
