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.
