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
See inline comments for what it does. Its main use is figuring out if
something has been caused by GTK's caching of CSS properties or if it's
a different problem.
GtkPlug directly handles X KeyPress/Release events, instead of using
translation in GDK (which expects XI2 events for XI2). When this
was done, the handling of the group was stubbed out and never replaced.
Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier()
so we can fill out the fields correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=675167
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 commit introduces GDK_TOUCH_BEGIN/UPDATE/END/CANCEL
and a separate GdkEventTouch struct that they use. This
is closer to the touch event API of other platforms and
matches the xi2 events closely, too.
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.
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
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.
This function can be used to find the GdkDevice wrapping
an XInput2 device ID. For core devices, the Virtual Core
Pointer/Keyboard IDs (2/3) may be used.
This function can be used to find out the XInput2 device ID
behind a GdkDevice, mostly useful when you need to interact
with say Clutter, or raw libXi calls.
The doc build for that is currently broken, and libgail-util is
undergoing reconstructive surgery anyway, currently.
Or maybe it'll turn out to be an amputation...
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.
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
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
GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird
things in gtk2. We should not have to carry this forwards in gtk 3.x.
We do however keep a g_warning() call reminding people of this fact to
ease debugging when they try to port their applications.
https://bugzilla.gnome.org/show_bug.cgi?id=644119
Now that a single shared object can contain multiple backends we also
need to provide a simple way for third party code to verify that the
copy of GDK they are linking to supports their backend.
The simplest way to verify is an m4 macro, GTK_CHECK_BACKEND(), shipped
with the gtk+ m4 macros.
The usage is pretty basic:
GTK_CHECK_BACKEND([x11], [gtk_has_x11=yes], [gtk_has_x11=no])
AM_CONDITIONAL(BUILD_X11_CODE, test "x$gtk_has_x11" = "xno")
https://bugzilla.gnome.org/show_bug.cgi?id=642479
At the same time, change the library sonames for -3.0 to just -3.
This is necessary since the 2.99 releases installed libraries like
libgtk-3.0.so.0.9903.0, and we want to prevent the library version
number from jumping back. So 3.0 will have libgtk-3.so.0.0.0.
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
... and all APIs making use of it.
That code like it hasn't been touched in years, Google codesearch
didn't find any users and most importantly it's a horrendous API, so
let's just make it die instead of having to port it over to
non-GdkNativeWindow usage, which would be required for multi-backend
GDK.
http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00049.html
I think it's confusing for a lot the developers out there who
may not even be aware of GTK+ 3 coming, if suddenly GTK+ 3 becomes
the "stable" version of "gtk" on library.gnome.org. It may
not even be feasible for them to port to GTK+3 if it's not
shipped in the operating systems they're targeting (for example,
RHEL 6).
Since practically speaking, we expect people to consume GTK+ 2 for
several years at least, redirect these people to the right pages.
(I didn't attempt to explain the differences between the libraries
here, but hopefully the major version difference is enough of a hint)
As a side effect, this makes the generated HTML look better; previously
it looked rather crappy, since the "for GTK &version;" was totally
offset and in a different group from the documentation title.
Also added documentation section for this. Since the GtkRecentFilter
documentation was still living in sgml, as a side-effect I migrated these
docs to the gtkrecentfilter.[ch] sources.
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).
When converting to gtk3, replace GtkComboBoxEntry with GtkComboxBox
has-entry=True, and remove the has-separator property from GtkDialogs.
Bug #639327.
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
In bug 635207, it was pointed out that it is a bad idea to
rename these tools purely in the name of parallel-installability,
since it forces dependencies to make a choice between running
gtk-update-icon-cache and gtk-update-icon-cache-3.0 (or both ?!).
So, we rename these utilities back to their un-suffixed names
and rely on distributors to resolve the conflict between GTK+ 2.x
and GTK+ 3.0 packages, which can be done e.g. by dropping the
utilities from the gtk3 packages and add a gtk3 -> gtk2 dependency.
When commenting out a binary, also comment out the related variables.
Don't include Makefile.decl in gtk-doc Makefile.am's as they disagree
on assigning to EXTRA_DIST.
There's no usecase for them, so remove them before we have to commit to
keeping an API.
Make the hooks private for now, actually removing them will come in
followup patches.
Its usecase was GERD - http://testbit.eu/~timj/historic/gerd/ - and that
project is long since dead.
I couldn't find any app using it after asking around and googling either.
Its usecase was GERD - http://testbit.eu/~timj/historic/gerd/ - and that
project is long since dead.
It has been superseded in GTK 2.2 by GdkDisplayPointerHooks anyway.
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.
Remove the --sync option and remove the possibility of backend-specific
commandline options altogether. --sync is being replaced by
a GDK_SYNCHRONIZE environment variable.
The X11 backend exports a number of symbols which are _-prefixed
(so don't become part of the gdk api), but are not named in a
way to prevent accidental clashes between backends.
The one API change here is that the gdk_xid_table functions
have been removed - they did not server an purpose, since the
xid table only stores windows anyway, and we already have a
lookup-by-xid function for windows.
These functions were trivial g_spawn wrappers in all backends
except for X11, and they can be easily replaced by
g_app_info_create_for_commandline + GdkAppLaunchContext.
