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.
It actually messed up with the state being actually set, and having a
transition animation running for it. Now this dichotomy is removed, and
gtk_style_context_state_is_running() only checks whether an animation is
running, leaving state checking to flags & GTK_STATE_FLAG_*.
Based on a patch by Matthias, add an "active-id" property for
GtkComboBox and add some convenience API for GtkComboBoxText.
Also, add a test case to gtk-demo.
It is really bad code, mostly unused and no one stepped up to fix it.
Note that Gtk developers do not object to a ruler widget in priciple,
just to the current implementation. If someone wants to propose a sane
version, please don't hesitate.
https://bugzilla.gnome.org/show_bug.cgi?id=613942
It is just too annoying to have to implement these properties in
every scrollable. Instead, we now have ::min-content-height/width
in GtkScrolledWindow.
We also add GtkScrollablePolicy to determine how to size the
scrollable content.
The GtkScrollable interface provides "hadjustment" and "vadjustment"
properties that are used by GtkScrolledWindow. It replaces
the ::set_scroll_adjustment signal. The scrollable interface
also has ::min-display-width/height properties that can be
used to control the minimally visible part inside a scrolled window.
Use input-only windows for capturing input, and just draw onto
the parent window. This allows themes to make entries with rounded
corners. Patch by Boram Park.
https://bugzilla.gnome.org/show_bug.cgi?id=632736
GtkComboBox now sports a construct-only "has-entry" property which
decides if it uses a GtkEntry to allow additional user input. Also
it has a new "entry-text-column" to fetch strings for the entry
from the model.
This patch deprecates the GtkComboBoxEntry and updates the rest of GTK+
to use the new semantics on GtkComboBox instead.
GtkComboBoxEntry will be removed altogether before GTK+ 3, in a
later commit.
We remove the resize grip from GtkStatusbar, but keep the code
that makes the content avoid the grip, and adapt it to GtkWindow
grips.
The gtk_status_bar_set/get_has_resize_grip() functions and related
properties are removed.
Allow any window to display a resize grip, in the south-east or
south-west corner, depending on text direction. This is implemented
as a shaped window that gets overlayed on top of whatever content
is there. We add api that allows widgets to avoid the resize grip,
if desired.
The ::has-resize-grip property controls if a window may display
a resize grip. It will only be displayed if the window is resizable
and not maximized.
The size and visual appearance of the resize grip is under theme
control, using the resize-grip-width/height style properties and
the paint_resize_grip style function.
It turns out that the previous handling of just providing a way to set
visuals just on toplevels was not sufficient. In particular it
complicated the various implementations of the tray icon specification.
This patch reintroduces gtk_widget_set_visual() which behaves very
similar to GTK2's gtk_widget_set_colormap().
A future commit will remove the gtk_window_set_visual() function.
The function reverses the transform that GTK does before emitting a draw
event. So we can use it in "old" widgets to revert the coordinate system
properly.
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
The functions are gtk_widget_get_allocated_width() and
gtk_widget_get_allocated_height().
They are currently identical to using width/height of
gtk_widget_get_allocation(), but are introduced for ease of use (no need
to use a custom struct) and to free people from having to think about
allocation.x and allocation.y (which is where the origin of the cairo
context in GtkWidget::draw is located).
This removes:
gtk_widget_set_default_colormap()
gtk_widget_get_default_colormap()
gtk_widget_get_default_visual()
Colormaps are gone, and the default visual is the system visual of the
default screen.
