summaryrefslogtreecommitdiff
path: root/gtk/gtkapplicationwindow.c
Commit message (Collapse)AuthorAgeFilesLines
* docs: trivial fixes in GtkApplication-related documentationSébastien Wilmet2016-04-191-3/+3
|
* GtkApplicationWindow: the help_overlay is nullableTimm Bäder2015-11-141-1/+1
|
* GtkApplicationWindow: Fix typosTimm Bäder2015-11-141-1/+1
|
* GtkApplicationWindow: Add missing annotationsTimm Bäder2015-10-221-1/+1
|
* Add automatic help overlay support to GtkApplicationMatthias Clasen2015-10-211-2/+76
| | | | | | | When the $(resource_prefix)/gtk/help-overlay.ui resource exists, load a GtkShortcutsWindow from it for each GtkApplicationWindow, and set up a win.show-help-overlay action with accels <Primary>F1 and <Primary>? to show it.
* Expand builder menu documentationMatthias Clasen2015-07-291-6/+24
| | | | List the supported attributes.
* GtkApplicationWindow: Fix small doc formatting issuesMatthias Clasen2015-04-261-3/+2
|
* GtkApplicationWindow: Documentation fixPatrick Welche2014-12-231-3/+3
| | | | | | gtk_builder_add_from_string takes more than 2 parameters. https://bugzilla.gnome.org/show_bug.cgi?id=741897
* GtkApplicationWindow: Use G_PARAM_EXPLICIT_NOTIFYMatthias Clasen2014-06-091-1/+1
|
* GtkApplicationWindow: Avoid a crashMatthias Clasen2014-06-091-4/+6
| | | | | In several places, we were not correctly dealing with the possibility of application not being set.
* applicationwindow: Properly unmap the menubar widgetBenjamin Otte2014-05-051-0/+13
|
* docs: fully break lines in examplesWilliam Jon McCann2014-02-121-1/+4
| | | | | | | | | Try to do a better job of keeping example content from being too wide. It is often rendered as <pre> text so the only time we can wrap it is in the source. It is best to full break lines at all punctuation and to try to keep the width under 70 chars or so.
* Docs: Remove all entities and turn off sgml modeMatthias Clasen2014-02-091-12/+9
| | | | | With all element markup gone, it is time to turn off sgml mode, and get rid of entities as well.
* docs: use proper quotesWilliam Jon McCann2014-02-051-2/+2
|
* docs: Don't use <xi:include>William Jon McCann2014-02-051-5/+1
|
* docs: use ` instead of <literal>William Jon McCann2014-02-041-3/+3
|
* docs: don't use <tag> docbook elementsWilliam Jon McCann2014-02-041-7/+7
|
* docs: fix last commitWilliam Jon McCann2014-02-041-1/+0
|
* docs: replace all <examples> with markdown headingsWilliam Jon McCann2014-02-041-3/+4
|
* docs: Identify examples that are C codeWilliam Jon McCann2014-01-291-2/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=723119
* docs: use |[ ]| instead of <programlisting></programlisting>William Jon McCann2014-01-291-5/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=723119
* GtkApplicationWindow: give up on handling disposeRyan Lortie2014-01-141-43/+2
| | | | | | | | | | | | | | | | | | | | Stop trying to deal with "theoretical possibilities". We can't possibly continue to be a faithful GActionGroup implementation across dispose because dispose has a side effect of removing everyone's signal handlers. The code that we ran after the dispose chainup to do all of the fancy signal emulation was therefore dead. The test that aimed to verify this was buggy itself due to an uninitialised variable, so really, it never worked at all. We keep the re-ordering of the chainup from the original commit to avoid having trouble with GtkActionMuxer and keep the checks in place that will prevent an outright segfault in the case that someone else tries to use the interface post-dispose. https://bugzilla.gnome.org/show_bug.cgi?id=722189
* gtkwindow: Rename get_decoration_size => get_shadow_widthJasper St. Pierre2014-01-101-2/+2
|
* Fix GtkApplicationWindow action group implementationRyan Lortie2014-01-071-3/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GtkApplicationWindow frees its internal action group on dispose for the usual reasons: to avoid the possibility of reference cycles caused by actions referring back to the window again. Unfortunately, if it happens to be inside of a GtkActionMuxer at the time that it is disposed, it will (eventually) be removed from the muxer after it has been disposed. Removing an action group from a muxer involves a call to g_action_group_list_actions() which will crash because the internal action group to which we normally delegate the call has been freed. A future patch that reworks the quartz menu code will introduce a use of GtkActionMuxer in a way that causes exactly this problem. We can guard against the problem in a number of ways. First, we can avoid the entire situation by ensuring that we are removed from the muxer before we destroy the action group. To this end, we delay destruction of the action group until after the chain-up to the dispose of GtkWindow (which is where the window is removed from the GtkApplication). Secondly, we can add checks to each of our GActionGroup and GActionMap implementation functions to check that the internal action group is still alive before we attempt to delegate to it. We have to be careful, though: because our _list_actions() call will suddenly be returning an empty list, people watching the group from outside will have expected to see "action-removed" calls for the now-missing items. Make sure we send those. but only if someone is watching. https://bugzilla.gnome.org/show_bug.cgi?id=710351
* Refactor GtkApplicationRyan Lortie2013-12-161-103/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gtkapplication.c has turned into a bit of an #ifdef mess over time, and many of the current checks are incorrect. As an example, if you build Gtk for wayland, and exclude the X11 backend, much of the functionality required by wayland (such as exporting menu models) will be disabled. Solve that by introducing a backend mechanism to GtkApplication (named GtkApplicationImpl) similar to the one in GApplication. Add backends for Wayland, X11 and Quartz, with X11 and Wayland sharing a common 'DBus' superclass. GtkApplicationImpl | /--------------+-------------------\ | | GtkApplicationImplDBus GtkApplicationImplQuartz | /-----------+-----------------\ | | GtkApplicationImplX11 GtkApplicationImplWayland GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as hooks for various things that the platform-specific backends may be interested in doing (startup, shutdown, managing windows, inhibit, etc.) With this change, all platform specific code has been removed from gtkapplication.c and gtkapplicationwindow.c (both of which are now free of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in gtkapplicationwindow.c). Additionally, because of the movement of the property-setting code out of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and friends) will be set on non-GtkApplicationWindows, such as dialogs. https://bugzilla.gnome.org/show_bug.cgi?id=720550
* Drop a reference to nonexisting APIMatthias Clasen2013-12-131-1/+1
| | | | | | The GtkApplicationWindow documentation had a reference to gtk_header_bar_set_show_fallback_app_menu(). That function no longer exists, so drop it.
* wayland: Set DBus properties after we've constructed the xdg_surfaceJasper St. Pierre2013-11-191-2/+2
|
* Small doc improvementsMatthias Clasen2013-11-161-1/+3
|
* Fix fallback menubar size allocationMatthias Clasen2013-11-161-0/+18
| | | | | | | | When the menubar inserted by GtkApplicationWindow is the widest widget in a csd window, its allocation gets cut short. Fix this by taking the decoration size into account while calculating the size request (it is implicitly taken into account in the size allocation phase by _gtk_window_set_allocation).
* GtkWindow: better app menu fallback for CSDMatthias Clasen2013-11-161-8/+4
| | | | | | | | Do the menubutton for app menu fallback ourselves in GtkWindow for the csd, non-custom titlebar case. This fits better with the way we handle other title buttons. Themes have control over the placement of this button by placing menu in the decoration-button-layout style property.
* GtkApplicationWindow: Avoid double fallback for the app menuMatthias Clasen2013-11-161-1/+7
| | | | | If we have a header bar which has the app menu fallback enabled, don't add the app menu to the fallback menubar.
* GtkApplicationWindow: avoid mis-allocationMatthias Clasen2013-11-121-11/+3
| | | | | | | | In the fallback case, we were adding the border width of the window twice, causing the content to be mis-positioned and cut off in some cases. https://bugzilla.gnome.org/show_bug.cgi?id=710909
* GtkApplication: a new approach to accelsRyan Lortie2013-10-151-143/+0
| | | | | | | | | | | | | | | | | | | Rework how accels are handled on GtkApplicationWindow. Instead of having GtkApplication fill the GtkAccelMap which is then used by GtkApplicationWindow to create a GtkAccelGroup filled with closures that is then associated with the window, do it directly. GtkApplication now keeps a list of accels and their actions. Accelerators on a GtkApplicationWindow ask GtkApplication to execute the appropriate action. This saves a fair bit of complexity and memory use (due to not having to create all those closures and accelmap entries). The new approach also supports multiple accels per action (although there is not yet a public API for it). This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
* Improve struct packing in various placesMatthias Clasen2013-09-211-1/+1
|
* wayland: restore support for the application menuGiovanni Campagna2013-09-031-2/+25
| | | | | | | | If the compositor supports the gtk-shell interface, use it to export the application ID, dbus name and paths that can be used for the application menu. https://bugzilla.gnome.org/show_bug.cgi?id=707129
* gtk: Use new macros for defining private dataEmmanuele Bassi2013-07-091-2/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=702996
* Fix accels added after the window was shown not workingBastien Nocera2013-05-131-0/+9
| | | | | | | | | | | | GtkApplicationWindow would only update its list of captured accels when realizing the window. This meant that keyboard shortcuts added after the window was realised (for example, added by plugins) would be non-functional. Solve this by updating our accels every time the accel map changes, not only when realizing the window. https://bugzilla.gnome.org/show_bug.cgi?id=700079
* csd: Drop content_windowMatthias Clasen2013-04-201-7/+0
| | | | | | | Instead of reparenting the content, use input-only windows to set cursors and capture clicks on the window frame. This avoids some of the problems that were introduced by content_window, such as black flashes and non-working opacity.
* Fix GtkApplicationWindow menubar placementMatthias Clasen2013-03-271-0/+7
| | | | | | | Since the menubar is part of the content, we need to give it the content_window as parent window, to make things work again. https://bugzilla.gnome.org/show_bug.cgi?id=696561
* window: Allow _gtk_window_set_allocation to return a modified allocationRob Bradford2013-03-171-4/+7
| | | | | | | | | | | 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.
* applicationwindow: fix mem leakCosimo Cecchi2013-01-211-0/+4
| | | | | | In the error path, code is leaking a ref to a GVariant. https://bugzilla.gnome.org/show_bug.cgi?id=692203
* gtkmodelmenu: simplify logic, expose bind APIRyan Lortie2012-09-171-2/+2
| | | | | | | | | | | | | | | Make the main (and only) entry-point to gtkmodelmenu.c the now-public gtk_menu_shell_bind_model(). Move the convenience constructors (gtk_menu_new_from_model() and gtk_menu_bar_new_from_model()) to their proper files. Remove the private header file. Simplify the code a bit by making the initial populate part of the bind() call. https://bugzilla.gnome.org/show_bug.cgi?id=682831
* GtkAccelLabel: add manual accel APIRyan Lortie2012-09-171-1/+1
| | | | | | | | | | | | | | | | | Add an API to GtkAccelLabel for hardcoding the accel key to be displayed (ie: allowing us to bypass the GtkAccelGroup lookup). Use that from the GMenuModel-based GtkMenu construction code instead of passing around the accel group. This makes accel labels work in bloatpad again. This patch effectively removes any hope of automatic runtime accel changes in GMenuModel-based menus without additional application support but it leaves the door open for this to be supported again in the future (if we decide that it's important). https://bugzilla.gnome.org/show_bug.cgi?id=683738
* GtkApplicationWindow: drop GActionMuxer useRyan Lortie2012-08-201-14/+0
| | | | | | There are no remaining users of the GActionMuxer in GtkApplicationWindow because they've all been ported over to using the one on GtkWidget (via GtkActionHelper, for the most part).
* Remove private appwindow observer creation APIRyan Lortie2012-08-201-16/+0
| | | | | | There are no remaining users of the GtkApplicationWindow API to create GSimpleActionObserver or to get the GActionObservable (ie: muxer) for the appwindow. Drop those APIs.
* ApplicationWindow: setup accels with widget muxerLars Uebernickel2012-08-201-14/+5
| | | | | Use the muxer from GtkWidget to setup the accels rather than our own local muxer (which will soon be removed).
* gtkmodelmenu: move to new action regimeRyan Lortie2012-08-201-1/+1
| | | | | | | | | Drop the explicit passing of GActionGroup into the GtkMenu(Bar) constructors and operate from the action context instead. With GtkMenuItem implementing GtkActionable, this turns out to be pretty easy (and most of the code can be removed from GtkModelMenuItem, including the GActionObserver implementation).
* Add two users of gtk_widget_insert_action_groupLars Uebernickel2012-08-201-0/+2
| | | | | | | | | | Each GtkWindow with an associated GtkApplication should add this as "app" to its action context. Each GtkApplicationWindow is its own GActionGroup, and it should add itself to itself with the prefix "win". There is now some duplication here because we have the new GActionMuxer hierarchy managed by GtkWidget, but GtkApplicationWindow still carries its own muxer. The redundancy will be removed in a future patch.
* Add an example for handling app menu fallbackMatthias Clasen2012-07-221-0/+8
| | | | | The example shows how to use a menu button instead of the default menubar when the shell doesn't show the app menu.
* docs: fix a number of typos and obsolete referencesCosimo Cecchi2012-07-021-1/+1
|
View Lorry Controller Status