It seems that alternate implementations of GtkFileChooserWidget
never materialized. The split between GtkFileChooserWidget and
GtkFileChooserDefault is awkward. The immediate problem is that
it makes it difficult to document the keybinding signals. So it
makes sense to drop the abstraction and just have one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=723157
When running on quartz, it is no longer expected for applications to
provide their own application menu. Instead, they should simply ensure
that they provide "app.about", "app.preferences" and "app.quit" actions
(which many apps are already doing).
A default menu will be shown that looks like the one presented by all
other Mac OS applications, containing menu items for the above actions,
as well as the typical "Hide app", "Hide Others and "Show All" items and
the "Services" submenu.
If an application does explicitly set an application menu (via
gtk_application_set_app_menu()) then it will be respected, as before.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
As the first composite widget in GTK+, this patch also
adds some Makefile mechanics to list the ui files as
dependencies of the global GTK+ resources, and adds the
initial test case where composite classes should be tested.
This is not ideal, we should have a real classic windows theme,
but at least its better than everything being pink, which is what
happens otherwise when theming is not enables.
It was problematic to maintain Raleigh going forward, as any
changes in it affected all themes. Also, its more robust if
each theme is a full standalone css rather than relying on
an inherited css base.
So, this changes Raleigh to a standalone theme that we can tweak
without accidentally breaking other themes, and makes the
default theme empty. In fact, we don't even add the default
provider anymore as its always empty.
