This allows adding a GActionGroup with a given name at an arbitrary
point in the widget tree.
This patch also adds an internal _get_action_muxer() API. Calling this
will create a GActionMuxer associated with the widget. The parent of
the muxer will be the muxer of the widget's conceptual parent. For
non-menus, that is the normal parent. For menus, it is the attach
widget.
In this way, we end up with a hierarchy of GActionMuxer that largely
reflects the hierarchy of GtkWidget, but only in places that the action
context has been requested. These muxers are the ones on which the
inserted actions groups are installed.
A following patch will add a user of this API.
This gets the current cell area of a particular item. Its similar
to gtk_tree_view_get_cell_area().
The code is extracted from gtk_icon_view_set_tooltip_cell which now
just calls the old code.
https://bugzilla.gnome.org/show_bug.cgi?id=678418
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
Kinetic scrolling is only done on touch devices, since it is
sort of meaningless on pointer devices, besides it implies
a different input event handling on child widgets that is
unnecessary there.
If the scrolling doesn't start after a long press, the scrolling is
cancelled and events are handled by child widgets normally.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window will allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the press-and-hold
timeout in order to operate on the scrolledwindow child.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
This seems a bit "too powerful" and unlikely to be used by most
applications. Remove it from now, until someone comes up with a strong
desire for it.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
This commit adds API that allows to add new named sections
to the Credits part of GtkAboutDialog, in addition to the
hardcoded sections for authors, documenters, artists and
translators.
https://bugzilla.gnome.org/show_bug.cgi?id=484693
gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
We don't expose ::quit-requested as API anymore. Instead, we expect
users to register inhibitors when needed. Without quit-requested,
there is no need for ::quit-cancelled and gtk_application_quit_response
anymore.
We still emit ::quit when the application is about to quit.
We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
This feels premature; we do have the fallback situation covered
adaequately with the menubar, and people can do their own creative
solutions with gtk_application_window_get_menu(), so we don't have
to offer a widget for this right now.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
If the scale has an origin (it will have one by default), GtkRange will
render the two sides before/after the current value with different style
classes, making it possible for themes to use different colors and
properties for the two areas.
This was possible in GTK 2 with style details, but got lost during the
road to 3.0.
https://bugzilla.gnome.org/show_bug.cgi?id=665140
The new function provides an API that takes the PangoLayout and index
as input params, this way it handles strong and weak cursors internally
factoring out all code duplicated in the widgets that need to render
cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
This is useful to e.g. theme notebook tabs differently according to
their position directly from the CSS sheet.
GtkNotebook support in a separate commit.
https://bugzilla.gnome.org/show_bug.cgi?id=659777
GtkFontButton already has a property named "font-name" which may
conflict / be an ABI break when moving GtkFontButton to implement
GtkFontChooser. Also, this is more in line with how other parts in
gtk (e.g. GtkCellRendererText) call a font string property.
Make the GtkFontChooser API similar to the Gtk{File,Recent,App}Chooser
APIs by introducing GtkFontChooser as an interface, that has a default
implementation in GtkFontChooserWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=657627
This struct keeps track of an area of text in a CSS file and uses it
when specifying information. Also, the cssprovider keeps track of
sections when parsing a file.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
This way themes can use GtkComboBox.combobox-entry to match that
specific case, and GtkComboBox.combobox-entry .button to match the
button/arrow side of the widget.
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.
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
Inheritance is now done using style property flags, so thereis no ned
anymore to clobber the pspec flags namespace.
Also, there is no need to expose this functionality in the public API
without exposing more of the styleproperty API.
This essentially reverts commit 9bfd3d2eec.
This is a special-purpose button that can be used together with
GPermission objects to control the sensitivity of system settings.
Suitable permission objects can e.g. be obtained from PolicyKit.
http://bugzilla.gnome.org/show_bug.cgi?id=626457
Dumps the widget path into a string representation. It tries to match the CSS
style as closely as possible (Note that there might be paths that cannot be
represented in CSS).
The main use of this code is for debugging purposes, so that you can
g_print() the path or dump it in a gdb session.
gtk_entry_set_placeholder_text() makes the entry display the given text
when it is empty and unfocused. Based on previous patch by Alberto
Garcia.
https://bugzilla.gnome.org/show_bug.cgi?id=440963
In GTK 3.0 it's no longer possible to e.g. pop up something
at a text view's cursor (this wasn't exactly possible before
either without including gtktextlayout, but this is a quite
special need anyway).
This function is a more convenient variant than
gtk_widget_set_device_events(), as it will
1) perform changes down a widget hierarchy, to
all windows.
1) use the same event mask than gdk_window_get_events()
This function will be needed in widgets like GtkTreeView,
since gdk_window_scroll() doesn't trigger the usual
mechanisms to update the invalidation area, this function
is needed together with it.
This function takes a region ID and cancels all animations
on or beneath that region (as in push/pop_animatable_region).
First user of this is GtkWidget itself, so unmapped widgets
have looping animations cancelled. Fixes bug #638119, reported
by Jesse van den Kieboom.
This is a subclass of GEmblemedIcon that can show a number or
short string as an emblem, overlayed on top of another emblem.
Written by Cosimo Cecchi
https://bugzilla.gnome.org/show_bug.cgi?id=637169
- Removed GtkTreeMenu from gtk-docs.sgml
- Removed GtkTreeMenu from gtk3-sections.txt
- Removed GtkTreeMenu from gtk.symbols
- Make GtkTreeMenu apis prefixed with '_' (including _get_type()).
- Updated GtkComboBox sources to use the private apis
- Updated GtkCellView to not mention #GtkTreeMenu in gtk-doc statements
- Updated tests/testtreemenu to not use a GtkTreeMenu but still
show a very fancy GtkComboBox
- Moved gtktreemenu.h to private headers section in the makefile.
- Removed include of gtktreemenu.h from gtk.h
The functions to set frames on windows stopped being interesting
when the linux framebuffer port was dropped, many years ago.
Similar functionality may come back with client-side decorations
in the future.
The old functions to get core pointer and devices list are gone as
well. This slice is entirely replaced internally by multidevice
handling and may just go.
Added gtk_cell_area_context_get_preferred_height_for_width and
width_for_height & gtk_cell_area_copy_context() to gtk.symbols
and gtk3-sections.txt (also finished up documenting those apis).
gtk_cell_area_foreach_alloc() itterates over an allocated list of cells
and calls a callback with the cell's allocation until the callback returns
TRUE.
- Removed vfunc get_cell_allocation() and implemented
gtk_cell_area_get_cell_allocation() using foreach_alloc()
- Added gtk_cell_area_get_cell_at_position() using foreach_alloc()
- Removed GtkCellAreaBox ->event() implementation and implemented
mouse "click" cell activation in GtkCellArea class directly using
gtk_cell_area_get_cell_at_position().
gtk_widget_override_*() deprecates gtk_widget_modify_*(). There are
only functions to modify fg/bg/font/symbolic color, If anything more
fancy/complex is needed. There is the possibility of adding a
GtkStyleProvider yourself.
gtk_widget_(set|unset|get)_state_flags() has been added, using GtkStateFlags
to represent the widget state. GtkStateType API has been implemented on top
of the new one.
