Provide a mechanism for hiding the "Quit", "About" and "Preferences"
menu items from the normal places in a traditional menubar layout (in
the File and Edit menus) when the menu is being rendered in the Mac OS
menubar.
These items can already be found in the application menu.
With this feature, applications can now define a single menu to use in
all 'traditional' scenarios.
Use this new attribute in Bloatpad.
https://bugzilla.gnome.org/show_bug.cgi?id=741610
Apparently it's not possible in GtkTextView to say "this style should
apply to all text, including newly inserted text. Or I'm just too stupid
to use its API.
So instead, keep using override_color().
We move our menus.ui file into Gtk's namespace so that it will get
picked up. Accordingly, we no longer have to do any of the work for
ourselves...
https://bugzilla.gnome.org/show_bug.cgi?id=722092
Move bloatpad to ./examples/bp/ so that we can start treating it as more of a
"normal" app instead of just jamming everything into a single .c file.
We don't use the name "bloatpad" for the directory in order not to
create 'git pull' pain with the probably-already-existing executable of
the same name.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
Cook up some silly cases to test out the hidden-when='' attribute.
- make sure hidden-when='action-missing' shows/hides items based on
actions being created and destroyed
- make sure hidden-when='action-disabled' shows/hides items based on
actions being enabled and disabled
- make sure hidden-when='action-missing' doesn't hide items when the
action is merely disabled
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Notifications can only be associated with application actions,
but clear is a window action. Introduce a "clear-all" action
that forwards to clear on all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=721633
Make the sunny example useful by giving it a header bar
with app menu fallback. To test this under gnome-shell,
set APP_MENU_FALLBACK=1 in the environment.
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Setting up the icon and desktop file is a pretty central part
of making an application work, so we should do it for our example.
The fact that the examples are uninstalled makes this a little
more complicated.
I disconnected signals in dispose() to avoid a visible-tab
change notification during destruction, but this is clunky.
Instead, make the notify::visible-tab signal handler bail out
early when called during destruction.
Add a new example to the getting started part of the docs. The focus
of this example is on 'new stuff': GtkApplication, templates, settings,
gmenu, gaction, GtkStack, GtkHeaderBar, GtkSearchBar, GtkRevealer,
GtkListBox, GtkMenuButton, etc.
It is being developed in several steps. Each step is put in a separate
directory below examples/: application1, ..., application8. This is a
little repetitive, but lets us use the code of all examples in the
documentation.
Add support for a stateful action associated with a submenu. The action
state is set to TRUE when the menu is shown and FALSE when it is
unshown.
This is useful to avoid unnecessary processing for menus that have
frequently-changing content.
A possible future feature is to add support for asynchronously filling
the initial state of the menu by waiting until the action actually emits
its state-change signal to TRUE before showing the menu.
A silly example has been added to Bloatpad to demonstrate the new
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=682630
The builder XML description has an action for "win.parse" but the
application is looking for "win.paste". Rename the label to
"_Paste" and the action to "win.paste" in the window action XML.
https://bugzilla.gnome.org/show_bug.cgi?id=678829
Change the format of GtkBuilder <menu> to be more in-line with the style
of the rest of GtkBuilder so that we can do translation in a consistent
way.
The format is now substantially more difficult to hand-write, but tools
should be along soon.
There is an xslt program attached to the bug to help you convert your
existing .ui files from the old format to the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=668696
Add a switch. This demonstrates:
- that switches can be placed in toolbars
- that GtkSwitch is actionable
- that actions can be shared between multiple actionables
We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
