Seems the redraw was not happenning from keynav when set_focus_cell()
was called because keynav already updates the focus-cell. Now we
just unconditionally redraw the focus item when set_focus_cell() is
called.
Icon View was not initially setting focus on a cell when
focus initially comes into the view. Focusing into whatever
is the first cell in the cursor item when set_cursor_item
is called with a NULL cell fixes this.
GtkIconView sets the minimum width of the text cell to be at least 50
pixels and otherwise twice the width of the first pixbuf cell found
in the icon list.
GtkIconView should have a "grow-only" mode to handle optimization to
only allow icons to grow in width when rows change, however since
GtkIconView still does not handle large numbers of rows for now we'll
just relayout the whole thing whenever a series of rows change.
Also fixed up to watch the context incase of implicit resets.
of each row.
GtkIconView now properly calculates the height of each row separately
using a separate GtkCellAreaContext stored in an array which it can
always easily index with the item->row index for all purposes.
However, I'm going to have to figure a way to store the alignments
for rows separately, this may involve using a separate GtkCellAreaContext
for each row, unfortunately.
Some things still not sorted out, GtkCellAreaContext is not allocated
so icons dont recieve alignments yet, focus navigation is not exactly
what it used to be (maybe we can work around that by observing the
item orientation and explicitly setting focus to the same cell when
navigating in the wrong orientation).
- 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
And updated gtk_combo_box_list_position() which is still waiting
for GtkTreeView to report natural width in order to properly do
non fixed width dropdown menus.
APIS: gtk_cell_view_get_desired_width_of_row &
gtk_cell_view_get_desired_height_for_width_of_row were introduced in
3.0 only for use from GtkComboBox and now the refactored cellview
does this transparently and just requests the right thing through
GtkWidget apis.
First iteration at implementing combo box using a delegate
treemenu, almost everything is working. Still need to finalize
sensitivity issues in GtkTreeMenu (and should go ahead and pass
through GtkComboBox code with a fine comb...).
- "fit-model" decides that the cellview should request space for
the entire treemodel, this ensures the cell view displayed on
a combo box will not spuriously change size when the selected
item changes.
- "draw-sensitive" forces cell area to render cells sensitive
even if they are insensitive in the model.
Added properties "wrap-width", "row-span-column" and "column-span-column"
to allow grid style menus from treemodels. Handling row data changes
appropriately.
Combo boxes expose an "add-tearoffs" feature to add a tearoff item to the root of the combo menu, added this feature to GtkTreeMenu to achieve this (and updated the testcase).
Now the GtkTreeMenu properly updates its hierarchy when the underlying
model data changes (row inserted/deleted or reordered). Also some unneeded
hackery was removed, all size calculations are delegated to the cellviews.
When the "row-changed" signal on the model is trapped, if the row which
changed is the displayed row then the context is flushed and sizes are
recalculated for every area in the same context.
GtkComboBox needs treemenus to allow selection of all leafs including
rows which may have children, this allows the combobox or combobox user
to decide which row that has children can also be selectable as a header
leaf of the submenu. Test case testtreemenu updated to reflect this.
GtkTreeMenu needs to only populate it's submenus when set_root()
is called, we were populating it when the model is set which cause
the tree to be infinitely populated as the root is NULL by default.
Also call gtk_menu_set_reserve_toggle_thingy (FALSE) to not reserve
space for the toggle size.
Added GtkTreeMenu class to automatically render
a GtkTreeModel into a GtkMenu hierarchy (will be
used by GtkComboBox for its dropdown menus). Included
an accompanying testcase tests/testtreemenu
This is needed by GtkTreeMenu to ensure that child menu items
reserve space for the submenu indicator even if they dont have
submenus... in this way we ensure the same size of all cell
areas in the menu items at allocation/request time.
Added construct GtkCellArea and GtkCellAreaContext properties,
the context property allows putting multiple cellviews into the
same size request context.
The show_submenu_indicator flag was explicitly set in various
places from GtkMenu/GtkMenuBar at request times, since the
GtkMenuItem already checks the parent type for GTK_IS_MENU_BAR()
in various places, removed this flag in favor of just checking
the parent type (only in the interest of better readable code).
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.
GtkWindow was only releasing the application in finalize, causing
problems for language bindings. Now we release it already in destroy
(and then again in finalize for good measure).
https://bugzilla.gnome.org/show_bug.cgi?id=638580
Prevents an Xlib warning on Xnest, or Xorg with xinerama, or other
non-RANDR-capable xserver. Reintroduce a have_randr12 field in
GdkDisplayX11 to avoid having to call XRRQuery{Extension,Version} twice,
and don't select randr 1.2 events if that's false.
https://bugzilla.gnome.org/show_bug.cgi?id=634711
Signed-off-by: Julien Cristau <jcristau@debian.org>
Only the big chunk of x11 checks is left further down in the file,
but that depends on variables and checks above it, so we'll leave that in
place for now.
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.
I neither know how to trigger this code nor what would be
the suggested replacement API. BUt it's the last thing stopping
me to compile GTK3 for win32.
Although gtk.symbols seems to be unused on Unix now it still
must not contain unprotected Unix only functions, because they
can not be exported on win32.
There are sure regressions but basic stuff seems to be working
again after all the API breakage done with comments like
"Win32 and Quartz need to be ported still."
Since "->adjust_size_request()" was added, it became important for GtkBin's
generic height-for-width implementation to further check the requests
using this vfunc.
of limiting it to it's minimum size.
This fixes height-for-width labels inside a GtkCheckButton, for some
reason GtkCheckButton was limiting the child allocation to the child's
minimum request, probably for the sake of virtual left-alignment of
the child label to be beside the checkmark. This should be done by
other means if nescesarry.
For "padding" cases, it would be ok to fallback on GtkBin class
implementation of height-for-width. However in cases where the
user set's an xscale/yscale the GtkAlignment needs to take care
of properly adjusting the for_size when querying it's child.
Checks were in place to ensure that widgets never request taller
or wider than screen size. This was there to test a theory about
scrolled window children functioning correctly with dynamic content
however it breaks GtkViewport children which can generally return a
value taller than screen height intentionally, GtkViewport uses this
value to update the adjustments.
The watcher doesn't add a window if is a redundant object. This
patch fixes two things:
* The check was made twice.
* It uses a check with the string "redundant object", when the
defined role ATK_ROLE_REDUNDANT_OBJECT is available
Only connect to the destroy of a toplevel window if it was
really added to the toplevel list of windows.
The destroy callback was added to remove the window from
the toplevel list. The callback doesn't cause a error,
but would iterate on the toplevel list without success.
We need to defer setting the default display until the
GdkDisplay is fully initialized. Also, short-circuit some
encoding conversions when creating windows, to avoid an
implicit dependency on the display being in the list of
displays yet.
This was an incomplete attempt to get rid of the custom free function.
Lets just keep it for now. Bug 637849, patch by Dan Winship.
Also add a test case for this function.
Normally HFS+ (the MacOSX file system) isn't case-sensitive, so having both
GtkQuartzWindow.h and gtkquartzwindow.h causes the latter to overwrite the
former during git pull, breaking the build.
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.
Usually pango_layout_get_pixel_extents() is used, which uses
PANGO_PIXELS_CEIL on the rectangle's width. This commit makes the new
function gtk_cell_renderer_text_get_preferred_width() consistent with
this.
This fixes rounding errors on Mac OS X, where we were seeing tree views
with a double height for a single line of text, while the usual single
row height would have been sufficient.
An overlooked API change in the gdk-backend work: many of the
keymap functions used to accept NULL to mean 'default keymap'.
They no longer do, so update the docs to match the new behaviour.
The 'Properties' button here is not really modifying the property
in any way, so it doesn't make sense to disable it just because
the object can only be set at construction.
This lets us poke at e.g. the cell area of an icon view.
This was claimed to cause problems for Chromium, see bug 599130.
Also work around apparent rounding errors in XIWarpDevice by
setting the 'small step' for keynav dnd to 2 instead of 1 - I notice
that a warp seems to sometimes warp a little less than I tell it to,
and if I tell it to only move by 1 pixel then moving less means
that you are stuck.
For normal toplevels, visible is tightly bound to mapped, but for
something like a toplevel that exists within a Clutter stage we
may want to make mapping dependenton external factors, so we shouldn't
actually checked that !mapped toplevels are !visible.
Pointed out by Owen Taylor,
https://bugzilla.gnome.org/show_bug.cgi?id=637834
Always returning NULL (no match) from gtk_rc_get_style_by_paths()
means that looking up colors and style properties based on the
GtkStyle will give default values instead of themed values. We can
do better by returning a GtkStyle based on a GtkWidgetPath that we
figure out from the values passed in to get_style_by_paths().
https://bugzilla.gnome.org/show_bug.cgi?id=637520
We want to have different window types for different displays, so we can
write code like this:
#if GDK_WINDOWING_X11
if (GDK_IS_X11_WINDOW (window))
{
/* do x11 stuff */
}
else
#endif
#if GDK_WINDOWING_WAYLAND
if (GDK_IS_WAYLAND_WINDOW (window))
{
/* do wayland stuff */
}
else
#endif
{
/* do stuff for unsupported system */
}
This requires different GdkWindow types and we currently don't have
that, as only the GdkWindowImpl differs. With this method, every backend
defines a custom type that's just a simple subclass of GdkWindow. This
way GdkWindow behaves like all the other types (visuals, screens,
displays) and we can write code like the above.
This is for compatibility reasons. We want to change APIs that operate
on X11 objects to take the X11 objects as arguments. However, this would
break a lot of APIs and we'd like to avoid this, so we play this little
trick (we will use the same trick for the other X11 objects). Also,
gobject-introspection and other bindings can correctly attach the
functions to the correct types as it is the same scheme that GDK2 used
for pixmaps, windows and drawables.
For GTK 4, we will remove this trick, so apps should properly cast their
objects right now.
Unfortunately, I don't think there is a way to use
GDK_DISABLE_DEPRECATED or similar macros to check for proper type casts
while compiling ensure compatibility with future GDK versions. I'm free
to consider them though.
Move everything dealing with compound text to be X11 specific
Only gdk_text_property_to_utf8_list and gdk_utf8_to_string_target
are kept across backends, so add vfuncs for these.
Also, remove the non-multihead-safe variants of all these.
Remove the --sync option and remove the possibility of backend-specific
commandline options altogether. --sync is being replaced by
a GDK_SYNCHRONIZE environment variable.
Moving the direct-access redefinitions of various macros
to gdkprivate-x11.h and use that header throughout in x11/.
Also remove a workaround for a long-fixed X server bug.
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.
Commandline arguments should go away altogether, but this one
goes first, since we then don't need to worry about
_gdk_windowing_substitute_screen_number anymore.
This commit hides the GdkDisplayManager instance and class structs,
adds vfuncs for listing displays, opening displays, and getting and
setting the default display. The X11 backend has a derived
GdkDisplayManagerX11.
The gdk_display_manager_get() function is responsible for deciding on
which of the compiled in backends to use. Currently, it consults the
GDK_BACKEND environment variable and falls back to x11.
Use the grab and ungrab vfuncs from the frontend instead of the
_gdk_windowing wrappers, and move some things around accordingly.
Again, only the X11 backend has been updated, other backends
need to be updated to match.
It turned out no vfuncs were necessary. I've decided to move
the screen member up to GdkVisual, since it is the same in all
backends. The X11 backend subclasses now, to add the X members
that it needs to keep track of. GdkVisual and GdkVisualClass
are hidden now.
This commit hides GdkDragContext and GdkDragContextClass, adds
vfuncs for most drag context functionality, and turns the X11 DND
implementation into GdkDragContextX11. We also add vfuncs to
GdkDisplay for gdk_drag_get_protocol and to GdkWindow for
gdk_drag_begin, and implemenet them for X11.
Other backends need similar treatment and are broken now.
Add a GdkDisplay::get_app_launch_context vfunc, and a
gdk_display_get_app_launch_context that for X11 returns a subclass.
For win32 and quartz, the implementations were trivial, so we
just return a new GdkAppLaunchContext without subclassing. Since
the type of the context now depends on the display,
gdk_app_launch_context_set_display is deprecated.
After this commit, pc files no longer include the gdk backend in
their name, and we no longer install a pc file for gdk. There is
now a single gtk+-3.0.pc file. It turns out a separate gtk+-x11-3.0.pc
file is not necessary, since gdkx.h doesn't have a separate include
directory that would have to be added to Cflags.
This commit does a number of things:
- remove some dead wchar configury from configure.ac and gdkconfig.h
- repurpose gdkconfig.h as header that contains GDK_WINDOWING_foo
macros for each included backend, include it in gdk.h and install
it in $includedir instead of below $libdir
- drop the backend from the library names
- build libgdk-3.0.la as a convenience lib and include it in libgtk-3.0.la
It does not yet enable building multiple backends at the same time.
Now a cell can either have a "fixed" size or it can have
an "aligned" starting point or both. "fixed" size cells take
no space when they are invisible.
Added _gtk_cell_area_set_cell_data_func_with_proxy() to be called by
gtk_cell_layout_set_cell_data_func() when the layouting object itself
is not the underlying cell area.
After the window removal a while ago, the calendar main window
was not properly moved in size_allocate. Also, we ought to hide/show
the windows in map/unmap, not keep them visible at all times.
Bug 634657
Previously, for performance reasons we would sometimes
skip invoking the unmap signal (and associated vfunc)
in favor of simply unrealizing. However, widgets then
had no way to clean stuff up when they were hidden
(but still inside a parent which was shown).
This patch also removes _gtk_tooltip_hide() which
was done in both unmap and unrealize in gtkwidget.c,
now can only be in unmap.
There are probably lots of things cleaned up in
unrealize that would now be better to move to unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=629923
Requires fixes to GtkContainer and GtkWindow to unmap their
children, rather than just withdrawing or hiding the container
window.
Requires fix to GtkHandleBox to chain up to GtkContainer unmap.
Historically we avoided these unmaps for efficiency reasons,
but these days it's a bigger problem that there's no way
for child widgets to know that one of their ancestors has
become unmapped.
These checks are a bit expensive so require --enable-debug=yes.
gtk_widget_verify_invariants() checks invariants mentioned
in docs/widget_system.txt in particular, and can verify
others in the future.
Some of the invariants in docs/widget_system.txt don't
in fact hold right now, so those are #if 0'd in this
patch pending someone fixing either the docs or the code.
gdk_test_simulate_*() uses XSendEvent, which doesn't currently work
with XI2/GenericEvents, so make tests use core events for the time
being. Luckily there's a lot more to test than low-level event
handling in these tests.
Most code in gtkrc.c has been turned into a no-op, but that one
reverting in public API (gtk_rc_scanner_new() and such). GtStyle
is also more shallow, now fully relies in the backing
GtkStyleContext and all connection to gtkrc.c has been removed.
GtkBinding has been also affected, there is no replacement yet
for custom keybindings in style files, so that piece of code that
hooked into gtkrc has been replaced by a FIXME so in the future
it may be added back.
In the process of removing all sealed members from headers.
At the same time, add a gtkwindowprivate.h header and move
all internal functions from gtkwindow.h there.
Running gnome-shell under valgrind, I saw the attached invalid write.
Basically we can destroy a window during event processing, and the old
window_remove_filters simply called g_free() on the filter, ignoring
the refcount. Then later in event processing we call filter->refcount--,
which is writing to free()d memory.
Fix this by centralizing list mutation and refcount handling inside
a new shared _gdk_window_filter_unref() function, and using that
everywhere.
==13876== Invalid write of size 4
==13876== at 0x446B181: gdk_event_apply_filters (gdkeventsource.c:86)
==13876== by 0x446B411: _gdk_events_queue (gdkeventsource.c:188)
==13876== by 0x44437EF: gdk_display_get_event (gdkdisplay.c:410)
==13876== by 0x446B009: gdk_event_source_dispatch (gdkeventsource.c:317)
==13876== by 0x4AB7159: g_main_context_dispatch (gmain.c:2436)
==13876== by 0x4AB7957: g_main_context_iterate.clone.5 (gmain.c:3087)
==13876== by 0x4AB806A: g_main_loop_run (gmain.c:3295)
==13876== by 0x8084D6B: main (main.c:722)
==13876== Address 0x1658bcac is 12 bytes inside a block of size 16 free'd
==13876== at 0x4005EAD: free (vg_replace_malloc.c:366)
==13876== by 0x4ABE515: g_free (gmem.c:263)
==13876== by 0x444BCC9: window_remove_filters (gdkwindow.c:1873)
==13876== by 0x4454BA3: _gdk_window_destroy_hierarchy (gdkwindow.c:2043)
==13876== by 0x447BF6E: gdk_window_destroy_notify (gdkwindow-x11.c:1115)
==13876== by 0x43588E2: _gtk_socket_windowing_filter_func (gtksocket-x11.c:518)
==13876== by 0x446B170: gdk_event_apply_filters (gdkeventsource.c:79)
==13876== by 0x446B411: _gdk_events_queue (gdkeventsource.c:188)
==13876== by 0x44437EF: gdk_display_get_event (gdkdisplay.c:410)
==13876== by 0x446B009: gdk_event_source_dispatch (gdkeventsource.c:317)
==13876== by 0x4AB7159: g_main_context_dispatch (gmain.c:2436)
==13876== by 0x4AB7957: g_main_context_iterate.clone.5 (gmain.c:3087)
https://bugzilla.gnome.org/show_bug.cgi?id=637464
Before hide_all was used on popup_window, which means popup_widget
was also unmapped. This is now no longer the case. This fixes
subsequent pop ups for appears-as-list == 1.
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.
Mention that it's safe to use <cell-packing> tag for any GtkCellLayout
in GTK+ since they *all* use an underlying GtkCellArea (at least they
will once the other branches land).
I have never really liked the updates done to the adjustments in
do_validate_rows() and other validation functions. But it is really
required. I have to come up with a real solution to this one day.
This fixes a GTK+ 3.0 regression. In GTK+ 2, the render method
on GtkCellRenderer had a expose_area parameter, typically set to
cell_area. This parameter was used for clipping cell content to be
rendered to the cell area (and thus clipping to within the focus
rectangle). During the rendering clean up this parameter was removed
and no clipping put back into place.
Since expose_area was usually equal to cell_area anyway, it does not make
sense to reintroduce the expose_area parameter. Instead, we do clipping at
two levels:
- in gtk_cell_renderer_render() we clip to background_area. We cannot
clip to cell_area here because we want to allow cell renderers to
render in the background area (e.g. background color/effect).
- cell renderers should clip to clip_area when rendering cell
content individually (as they had to individually clip to expose_region
before).
Check (x, y) is inside background area. If yes, continue processing
and clamp the coordinates into cell area. This way we will properly
handle getting a cell (which is only used for setting the focus cell)
for clicks in the indentation area (in LTR and RTL mode) and clicks
in the focus rectangle area in case focus-line-width is large.
The cell's focus rectangle is located around the cell's aligned area.
To get to the correct coordinates for this rectangle, we have to subtract
focus_line_width from the found aligned_area.
Size requests should only ever need to return the screen's width/height
and max. This way, potentially large widgets (tree view or icon view)
don't need to do so many computations, but can stop when their computed
size has reached the screen size.
When setting no shape on an unshaped window, nothing changes,
so return early instead of recomputing lots of visibility
information.
Pointed out by Owen Taylor in bug 637156.
This function will enable events for all devices of a given
GdkInputSource, either these available at the time of the call,
or these that are connected in the future.
The xi2 device manager now handles slaves being detached and/or
attached to a master.
gdk_device_list_slaves() has been added so it is possible to
know how slaves relate with masters. The other backends (X11 and not)
don't neeed to to anything special here since their hierarchy is
fully flat.
When the slave device changes, the master takes the shape of the
new one, modifying its axes, this signal is more useful to catch
this situation than the n-axes property
This function may be used to know the hardware device that triggered
an event, it could resort to the master device in the few cases there's
not a direct hardware device to relate to the event (i.e.: crossing events
due to grabs)
gdk_enable_multidevice() has been replaced with gdk_disable_multidevice(),
so applications may call that function if they want to go back at the
previous behavior.
There would be usually little reasons to call that function, unless the
application is doing X calls itself that count on old fashioned core
devices.
This is a modernization of the GtkAboutDialog look done
by William Jon McCann. The most noteworthy changes are:
- no more subdialogs
- show license short text in the main dialog
- less verbose email link formatting
- the dialog is modal to its transient parent
All colors are defined now in the default css, and classes have
been added so the bars are fully themeable (as opposed to
gtk_widget_override_*, which require changing the color map itself)
For example, for an entry within a notebook, previously these 2 rules would
have the same weight:
.entry {}
.notebook {}
Now ".entry" will rank higher than ".notebook" for the GtkEntry, further
specific selectors such as:
.notebook .entry {}
still get a higher score than the previous ones.
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).
When focus is initially grabbed and there is no focus column, when selecting
the first column for focus, further explicitly focus into the first cell
using gtk_cell_area_focus().
the edge.
When focusing left/right or up/down inside GtkCellArea, now we save what
was the last focused cell and if we hit the side (or top or bottom) of
the view we then restore focus to the last focused cell.
This function did alot of nothing, gtk_cell_area_focus() simply returns whether
the focus stays in the area (column) or not, seems not to cause regressions to
just call it directly instead.
Added a few apis,
- GtkCellAreaContext get_preferred_height_for_width &
width for height apis and vfuncs, this lets the icon view
request the collective (and aligned) height for width for
a said row.
- gtk_cell_area_copy_context() this creates a duplicate of
an already created and requested context, this way the icon
view uses a global context to request the widths of all rows
and then makes a copy with all the stored alignments and
uses a separate copy to calculate the height and alignments
of each row separately.
Instead this is now enforced in gtk_tree_view_get_cell_area_height().
There are rows for which a height in between 0 and expander_size is
allowed, for example separator rows.
This argument allows the caller to specify that only an editable
cell should start editing but an activatable cell should not toggle
it's state, this is important for public apis like
gtk_tree_view_set_cursor_on_cell() which are only intended to
programatically bring attention to the editing of a specific
row or cell but not actually change any data.
GtkTreeView & CellAreaScaffold updated for the last minute api change.
No longer need to detect if we're currently resetting the context since
the context properly now avoids re-triggering the reset by properly
avoiding to notify properties that dont change as a result of the reset.
If the GtkComboBoxText doesn't have id-column or entry-text-column
set for some reason (value -1), better warn and return. Else, unrelated
assertions fail, and warnings from gtk_tree_model_get_column_type()
are printed, which are not really obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=637018
This allows us to reduce code allocation code paths in subclasses, as
a result GtkCellArea implements the ->render() vfunc and the subclass
only decides the cell area and background area distributions in a single
code path.
Move the guide into the 2-to-3 guide, since it is something
you have to do when porting from 2 to 3. Also add an example
for handling of temporary state changes and some more text
about color handling.
This allows us to add a check before executing
->get_preferred_height_for_width() to ensure we always
request for at least the minimum required size (and lets
us remove the warning in gtkcontainer.c telling implementors
to do this check manually from thier container implementations).
This fix is incorrect, treeviews dont rely on the expander size for drawing
separator rows (added XXX comment in line), need to fix this somewhere else
Scanner doesn't detect this case correctly because it's a typedef;
work around it here by explicitly specifying that it's caller
allocates. See bug 636393 for the scanner issue.
Commit 39f5740763 bumped the
autoconf version to 2.64 with no explicit rationale. It looks
to me like a copy-and-paste error. Reverting back to 2.62 (the
previous version). 2.63 at least (RHEL6) works here.
- Dont try fetching a cell renderer for an event when the event
coordinate is outside the cell area allocation (can happen
on the y axis, not all events are button events).
- Dont remove focus-line-width (inner area) an extra time from
GtkCellArea->event
- Dont remove focus-line-width from the cell area at all for the
editable widget... use the whole area including the focus line
(compared with git master behaviour and now it looks right, check
the multiline editable string in testtreeedit).
This fixes autosize columns... result can be viewable by checking
tests/testtreeview and setting the second column to autosize and then
expanding/colapsing some rows.
Now we bookkeep the treeview assigned padding asides from the
requested width stored in the GtkCellAreaContext, this removes
the need for bookkeeping the deepest expanded depth in gtktreeview.c
At allocation time, just remove the padding from the allocated width
of the column and feed the rest to the underlying cell area.
The recent improvements to error reporting caused gtk_css_provider_load...
to always return TRUE and leave the error unset. Error messages were instead
dumped out with g_message, which is not helpful.
This commit changes things back to the way they were before:
If a GError is passed in, parsing will fail at the first error, reporting
it in the given GError. If no GError is passed in, we keep going and
just issue the warning messages. This fixes the parser tests.
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().
The function has been re-implemented around GtkCellArea. This commits
also brings back the invocation of this function in
gtk_tree_view_button_press(). I shouldn't have removed this.
Now consult gtk_cell_area_context_get_preferred_height().
It can be that height-for-widths requested here were too large
when multiple cells are in play because of the alignments stored
in the context... removing the temporary focus-line-width hack.
Allow feeding treeviewcolumn a custom cell-area (or not a custom one,
but allow sharing the cell-area with say, the combo-box area).
This patch also:
- Fixes signal connections to the area (now they do eventually get
disconnected at dispose time, they are handled regardless if a
treeview is set but execute safely, at least there is only one
connection/disconnection).
- Fixes refcounting on the cell_area (GtkCellArea is GInitiallyUnowned).
- Adds a constructor() in order to build the cell-area if one has
not been provided by the caller before hand at g_object_new()
construct time.
This is a premature patch, it traverses the tree's expanded
rows and fetches the deepest depth every time we allocate a
column. The deepest depth should rather be cached and pushed
when a row expands, then recalculated when the deepest expanded
row collapses.
Removed gtk_tree_view_get_real_requested_width_from_column() from
gtktreeview.c in favor of this function in the treeviewcolumn domain
(since this function goes and checks treeviewcolumn internals, settings
and derives the real requested width, seems logical this should be done
by the treeviewcolumn instead).
Now the GtkTreeViewColumn takes care of move/resizing its window and
allocating its button (except for the special case of current drag_column
where the column doesnt actually get reallocated).
Some details:
- button_request was not needed, consult the minimum request of the button
- gtk_tree_view_column_get_button() needed to be public as people can set
tooltips on the button (and libgail accesses the button).
Nicer error reports are provided, and a GError can be spread from
anywhere in parsing, so over time more precise and meaningful
messages can be produced.
This object backs up gtk_widget_override_* operations. This object
is not meant to be public because any intention to modify widgets'
style in a themeable way should involve using regions/classes, so
they're modifiable through CSS. As such, the API is really
short-scoped.
All current users of this CSS property have been updated to deal
with a GtkBorder.
Also a 0 border width has been set in the default CSS to ensure
GtkStyleContext and GtkThemingEngine always provide a non-NULL
pointer for this property.
Background will be actually rotated in tabs, so the "bottom" side coincides
with the junction point, this makes gradients work as expected in rotated tabs.
This patch adds more detail to the explanation of CSS, and also
adds documentation about which files are read.
We also make :focus an alternative to :focused (since :focus is
a standard CSS pseudo-class).
Things like font settings depend on the screen, and widgets
like GtkTextView trigger queries on widgets without screen
when the parent window is being destroyed.
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.
This method will render progress bars and spinners, these should
handle active and inconsistent states' animation progress in order
to perform animations.
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.
"foreground-color" has been renamed to just "color" as in regular CSS,
and the "text-color" and "base-color" properties have been removed. The
default CSS has been changed to have widgets cope with this change.
Now selectors such as:
GtkWidget#name.class1.class2
#name.class1.class2
.class1.class2
are parsed correctly, being meaningful for a widget defining several
classes.
This property is to be set by theming engines, the name set will be favored
over the object type name when registering custom properties, making possible
something like:
-Clearlooks-border: blah;
The "alpha" symbolic color modifies a passed color's alpha by a factor,
the syntax would accept things like:
background-color: alpha (@bg_color, 0.8);
foreground-color: alpha (shade (@fg_color, 0.8), 0.5);
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_*.
The case for paned can be guessed out from the height and width,
for handlebox the orientation parameter doesn't make much sense,
and this way it could also be used for resize grips.
The css parser has been modified to parse correctly radial gradients:
background-image: -gtk-gradient (radial,
center center, 0,
center center, 0.8,
from (#000), to (#fff));
The theming engine has been modified to correctly animate these,
as well as transitions between different pattern types.
This is now used throughout in order to have the full path for a given widget,
including intermediate named regions, the default implementation just returns
the GtkContainer's path copy, no intermediate regions between.
Given there are other rules such as @import (which will be supported),
keep a sane namespace here, so for (re)defining a color name, in the CSS
file it will look like:
@define-color color-name #fff;
@define-color other-color mix (@color-name, #f00, 0.4);
The value it parses is similar to the border-image CSS3 property,
so strings like this will be accepted:
border-image: url (foo.png) 4 3 4 3 repeat repeat;
the image path is relative to the parsed CSS file dirname if no
absolute path is provided.
This type defines a gradient between 2 symbolic colors, with any number
of color stop between these. At the moment it has been put besides
GtkSymbolicColor, although should be completely private, it will likely
need extending in the future for radial gradients.
At some point, it maybe should also be used for images, so painting
both a gradient and an image is consistent.
Animation regions are confined through gtk_style_context_[push|pop]_animatable_region,
anything that's painted between these calls will be invalidated if an animation starts
for any of the regions in the stack.
gtk_style_context_notify_state_change() may be called from widgets to indicate a
change for a given GtkStateType, in that case an animation will be started if there
is an animation description for the widget/state.
This struct will be used to represent an animation in GtkStyleSet. It
will only be used internally in GtkStyleContext in order to trigger
animations, engines shouldn't need this.
This will only be used internally by GtkStyleContext in order
to animate state changes. When a proper animation framework is
introduced in GTK+, it may be ditched.
This support goes from the theming engines, which are able to retrieve
style for different combined states to the CSS provider, where several
state pseudo-classes may be specified, such as:
GtkButton:active:prelight {}
GtkStyleRegion has been renamed to GtkStyleInfo, as it doesn't really
have much to do with regions itself, the information it contains does.
This struct is used in save/restore.
This function may be used for custom property registration from
theming engines. The property names will have the
-${engine-type-name}-${prop-name} format, the parser has been
modified to allow properties with '-' as the first char.
There's now a distinction between:
GtkLabel#label-name: Label with name "label-name"
GtkWindow #label-name: Window containing a widget named "label-name"
Some unparented widgets like to ask style details, so now the style is
constructed regardless of the parent being present or not, and then
reconstructed if the parent changes.
These are of the form:
@color-a: #fff;
@color-b: mix (@color-a, #000, 0.5)
@color-c: shade (@color-b, 0.7)
In the stylesheet, arbitrary nesting of these commands is handled.
gtk_style_set_set_property() now takes both GdkColor and GtkSymbolicColor
GValues, All accessors still return GdkColors, so any symbolic color will
be resolved and replaced in the styleset at that time.
Style properties in the resource files are something like:
-GtkComboBox-appears-as-string
-GtkEntry-icon-prelight
Following the usual naming spec for extensions to CSS.
This will set the default value to a given property for all possible states,
such default value will only be used if the queried state doesn't have a
value itself.
This commit should probably be squashed in the future, when GtkStyleContext
is on par with it, and GtkStyle is just a shallow object on top of
GtkStyleContext and calling it in the default implementation methods, so
all gtk_paint_* and gtk_draw_* would work.
The wrong list was being modified in gtk_style_context_set_child_class(),
and gtk_style_context_has_child_class() was checking for *flags != 0, not
flags != NULL.
Now, selectors like:
GtkWindow > GtkButton {}
GtkNotebook > GtkLabel {}
will represent a direct parent/child relation between both elements, while
GtkWindow GtkButton {}
GtkNotebook GtkLabel {}
will allow intermediate children between these.
Now state is now defined as a pseudoclass in the CSS format, selectors like:
GtkWidget:active { }
GtkButton:insensitive { }
GtkCalendar:prelight { } (also :hover is accepted)
...
define the style for the given state.
GtkCssProvider is a GtkStyleProvider implementation which is able to read
CSS-like input to style widgets.
At the moment, only the basic parser features are available.
GtkThemingEngine will be the theming engines base class, with default
implementations for all paint functions, and readonly access to the
related GtkStyleContext data.
GtkWidgetPath represents a widget path. It will mainly used by theming
engines to know detail about the widget hierarchy without actually
accessing the widget.
There will be one GtkStyleContext per widget, at the moment its
lifetime is tied to the widget's, but it could be narrowed down
to GTK_WIDGET_REALIZED.
the ->focus() method was getting mixed up when more than
one cell was in the same group (not aligned), added the
proper check to break out of the loop on time.
- Removed most of GtkCellLayout implementation in favor of ->get_area()
- This allows GtkBuildable cell layout implementation to implement
the child "cell-properties"
- Also allows feeding a custom/different GtkCellArea implementation to
layout cells.
- Share the internal area with the created GtkTreeViewColumn.
Now consult gtk_cell_area_context_get_preferred_height().
It can be that height-for-widths requested here were too large
when multiple cells are in play because of the alignments stored
in the context... removing the temporary focus-line-width hack.
Allow feeding treeviewcolumn a custom cell-area (or not a custom one,
but allow sharing the cell-area with say, the combo-box area).
This patch also:
- Fixes signal connections to the area (now they do eventually get
disconnected at dispose time, they are handled regardless if a
treeview is set but execute safely, at least there is only one
connection/disconnection).
- Fixes refcounting on the cell_area (GtkCellArea is GInitiallyUnowned).
- Adds a constructor() in order to build the cell-area if one has
not been provided by the caller before hand at g_object_new()
construct time.
One less magic function. Also refactored it to make it easier to
implement. It now returns TRUE if it beeped and FALSE if it failed to do
so. A default implementation exists that just returns FALSE for all the
backends that can't beep windows (read: everything but X11 with XKB -
and why on earth do keyboard libs implement beeping?)
Trying to get rid of all the _gdk_windowing_something() functions that
we expect backends to magically know about and instead put them in a
proper interface (mostly GdkWindowImplClass).
... instead of _gdk_drawable_ref_cairo_surface() where appropriate.
Also, don't implement the drawable->create_cairo_surface vfunc anymore.
This is in preparation for the split of GdkWindow from GdkDrawable.
You are not allowed to track surfaces from GDK or draw outside of expose
events. So we can remove ugly hacks needed previously. See
https://bugzilla.gnome.org/show_bug.cgi?id=606009 for the introduction
of this workaround.
This is not strictly an API change as GdkDrawable is typedeffed to
GdkWindow, but it changes the header, so I'm marking it as such.
gdk_cairo_create() can only be used with windows these days, so it makes
sense to pass a window. With that, we can alseo remove the
set_cairo_clip() vfunc from GdkDrawable and implement it inside
gdkwindow.c.
You should not ever ever ever call cairo_reset_clip(). If you do, your
code is broken and you deserve everything you get.
And we should definitely not support this insanity.
This fix has evolved in the staging branch since all column members are
on a private structure, but since it causes warnings when closing the
windows of the testcellarea test (because the combo-boxes use a treeviewcolumn)
I thought it nice for now to just manually include the fix.
The fix is just proper bookkeeping of delegate objects at dispose() time.
It's a better test case if the scaffolding only displays the rows from top
to bottom and doesnt line up the cells from left to right (because it shows
that height-for-width still works with vertically oriented areas).
- When we reach a cell that is out of the render area, break out
of the loop (for columns user resized too small)
- CLAMP the size of the last renderer to fit into the area
(so that renderers get a chance to ellipsize when rendered
with a space less than allocation, same reason as above).
- Hand out remaining space in the render area to the last cell,
this is for shallow rows in the expand column which may recieve
more than the allocated width.
If the area has no activatable cells and has focus when
focus should be cycled, immediately focus out of the area
(because focus in that case is given to the entire area).
Thomas Wood pointed out that the original MxGtkLightSwitch widget upon
which I based the behaviour of GtkSwitch was not written by him; the
original authors are:
Joshua Lock
Robert Staudinger
Jussi Kukkonen
My apologies to all of them.
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.
ATK provides macros to the same effect as G_DEFINE_TYPE; using these
macros has the advantage of removing tons of duplicated code and
reducing the maintainership burden.
The widgets with inline accessibility implementation should switch to
these macros, and clean up the code.
https://bugzilla.gnome.org/show_bug.cgi?id=636060
ATK provides macros to the same effect as G_DEFINE_TYPE; using these
macros has the advantage of removing tons of duplicated code and
reducing the maintainership burden.
The widgets with inline accessibility implementation should switch to
these macros, and clean up the code.
https://bugzilla.gnome.org/show_bug.cgi?id=636060
This needs more work, currently we do dupe targets when copying
target entries in various places, and consequently free them
later. To do this correctly, the strings need to be interned
or something like that.
- the _get_default() method is now async
- the PackageKit module will return NULL in case PackageKit is not
available in the session bus
- the dummy module doesn't exist anymore
- the dialog won't display the online button in case there's no module
available
Introduce a 'custom-item-activated' on the widget, which behaves
similairly to GtkEntryCompletion::action-activated, i.e. is emitted when
a custom item is chosen from the dropdown list.
Clients can use the name provided when adding the item as a detail for
the signal, to get notified when that specific item is activated, or use
the signal without details to get notifications for all custom items.
The GtkSwitch widget is a simple UI control that has two states: on and
off. Toggling between the states is possible by clicking the widget or
by dragging the handle.
https://bugzilla.gnome.org/show_bug.cgi?id=634987
This is because focus in treeviews can be given to cells that cannot do anything
with activation (for better keynav), so we dissociate the concept of cell
activation and focusing.
Since GtkCellArea delegate does all the work, cell layout widgets
who use a GtkCellArea internally only have to implement the _get_area()
method, this just reduces code to forward the calls over the the internal
cell area.
Turns out theres not much reason to do this in a separate api,
now we just sum up the sizes of aligned cell groups in GtkCellAreaContextBox
when pushing the group size.
Since parse() is a method of the Gdk.RGBA class, the GdkRGBA pointer
should be the first argument, and the string the second one, to allow a
more natural binding.
https://bugzilla.gnome.org/show_bug.cgi?id=635879
This is still very much a work in progress, but it renders and more or
less works. I will be fixing up the details in the very near future.
Important: this commit breaks ABI as it modifies the GtkTreeViewColumn
structure in gtktreeviewcolumn.h. This is a sealed structure that needs
to be moved to an internal header file, most likely gtktreeprivate.h.
Slight tweak for GtkTreeView, also non-editable cells must be able to receive
focus to get all keyboard navigation right. This will be further tweaked
to get focus siblings to work like focus cells did in GtkTreeView before
refactoring.
The allocated size, or (horizontally speaking) for-width size, can be
smaller than the sum of all minimum widths. For example when the user
is resizing tree view columns manually.
What this means is basically that a vertically oriented GtkCellAreaBox
will render cells properly even if the height is not constant for every
for of data in the said GtkCellAreaContext (i.e. the height was not allocated
by gtk_cell_area_context_allocate).
This is done completely on the fly and so is much more heavy duty
at render time (considerably slower but not visibly noticable in
lightweight views like GtkTreeMenu). Note that cell alignments
are not possible in an unallocated orientation, each row of data
individually receives only enough space to render the independant
row and no space is reserved for alignments if the size is not
a constant size across rows in the same context.
Since a cell renderer might use more space than the natural
size when recieving expand space it's impossible to know how
much space is actually used to render content.
Adding this virtual method to allow text renderers to implement
it, the base default method uses height-for-width apis and aligns
the cell assuming the renderer uses a fixed size.
This commit removes the similar code from gtkcellarea and
subclasses.
- gtk_cell_area_context_get_height_for_width()
- gtk_cell_area_context_get_width_for_height()
- gtk_cell_area_context_push_height_for_width()
- gtk_cell_area_context_push_width_for_height()
- gtk_cell_area_context_flush_height_for_width()
- gtk_cell_area_context_flush_width_for_height()
- Contextual size changed signal
All of these are not really important for the CellArea to operate
and not of any real consequential value to the user (the user can
accumulate the returned values from height-for-width requests
and do as they please with it).
This is so that treeviews can have some columns oriented vertically and
some horizontally, usually the column will only allocate the areas
width, having vertical columns without fixed row heights just means
it's slower to render.
Since Havoc's patches introducing the GtkWidget halign/valign
properties, fill should always be TRUE. If the widget should
not fill its allocated space then it should set the halign or
valign properties for that purpose.
This also consequently fixes bug 634592.
This commit adjusts the app chooser code to GTK+ coding style:
- line up prototypes
- remove some excess {}
- remove tabs and trailing whitespace
- add docs
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
We can enable on-demand one of the three sections (recommended,
fallback, other apps) or use the special ALL property to display everything
uncategorized.
These properties are also easily bindable from outside.
It's implemented with a GIOExtensionPoint, which has two
implementations:
- a dummy one, which just errors out
- a PackageKit one, which looks up for the specified content type using
the PK DBus API and GDBus.
The PK module is optional, and can be compiled out at configure time.
TODO: a Win32 implementation of the module.
Like GtkFileChooser does; GtkOpenWith is a generic interface, which is
now implemented by both GtkOpenWithDialog and GtkOpenWithWidget (and in
the future also by GtkOpenWithComboBox).
We have three modes of showing applications now:
- RECOMMENDED mode: shows only the recommended applications
- ALL mode: shows all applications, uncategorized
- HEADINGS: shows headings for recommended and other applications
(default).
- _set/get_show_other_applications() is a way to only display
recommended applications in the dialog
- _set/get_show_set_as_default_button() is a way to control the
"Remember this application" checkbox
We also get rid of he "application-selected" signal, in favour of a
_get_selected_application() API inspired by GtkFileChooser.
Made gtk_cell_area_apply_attributes use a vfunc & signal so that
subclasses might do specialized things picking up attributes from the
model possibly for embedding widgets, and as specially for GtkTreeMenu
to connect to the signal and synchronize the menu sensitivity states
in a more convenient way than going through the GtkCellLayoutDataFunc.
An event filter may add or remove filters itself. This patch does
two things to address this case. The first is to take a temporary
reference to the filter while it is being used. The second is
to wait until after the filter function is run before determining
the next node in the list to process. This guards against
changes to the next node. It also does not run functions
that have been marked as removed. Though I'm not sure if this
case can arise.
https://bugzilla.gnome.org/show_bug.cgi?id=635380
In the current introspection data, the various gtk_radio_button_new_*
constructors take an existing group or widget. These all allow passing a NULL
widget or group list, so that it becomes easy to build a radio button list in a
loop (pass in None the first time, and the previously created button in all
other iterations).
Add the missing "allow-none" tag to the introspection data, so that this will
also eventually work for GIR users. NB that it does not actually work for some
constructors yet (like new_with_label_from_widget()) due to
https://bugzilla.gnome.org/show_bug.cgi?id=561264.
https://bugzilla.gnome.org/show_bug.cgi?id=635253
Since what we are doing is turning an icon with alpha into a
no-alpha icon + mask for legacy window managers, it makes more sense
to use the system visual than the window's visual, which might
be ARGB.
https://bugzilla.gnome.org/show_bug.cgi?id=634821
Now gtk_widget_size_allocate() unsets the resize_needed flags
before returning, essentially this means that any widget that
has a queued resize and is allocated before resize time, including
queued resizes from inside a size_allocate() method will be
cancelled.
when GtkEntry had visible windows, it was never noticed that we always
draw the frame, because the text_area window would cover it if
draw_frame was FALSE.
gdk_settings_map needs to be updated when gdk_settings_names is changed,
and it's easier to add the setting at the end, so we don't need to
recalculate everything.
Really fixing:
https://bugzilla.gnome.org/show_bug.cgi?id=634697
gdk_settings_map needs to be updated when gdk_settings_names is changed,
and it's easier to add the setting at the end, so we don't need to
recalculate everything.
Really fixing:
https://bugzilla.gnome.org/show_bug.cgi?id=634697
In this case, gnome-terminal sets an RGBA visual on its window,
and we need to be careful when creating the icon pixmap, to create
the pixmap with the same depth as the visual, or we risk a BadMatch
from XRenderCreatePicture deep inside cairo.
Set default directory to G_USER_DIRECTORY_DOCUMENTS
when printing to file backend and fallback to the current
directory when it is not available (#633896).
-removed headers that ceased to exist
-bump API version
-made up for new headers that is to be installed
-gtk-demo program and related sources/data copied to bin/gtk3-demo
Debian changed the behavior of libtool to not follow dependencies
from .la files. Fortunately, the scanner explicitly looks at the
.la files to see if they're really shared; if not it doesn't add
them to the .gir, so there's no cost.
https://bugzilla.gnome.org/show_bug.cgi?id=633405
This is just a private convenience function, and exporting _-prefixed
functions doesn't work with our libtool setup. Just do the 3 line
calculation in gail.
In this case, gnome-terminal sets an RGBA visual on its window,
and we need to be careful when creating the icon pixmap, to create
the pixmap with the same depth as the visual, or we risk a BadMatch
from XRenderCreatePicture deep inside cairo.
CellAreaScaffold now also reflects how cell_area should be
passed to gtk_cell_area_activate() and gtk_cell_area_event()
and how the background area for gtk_cell_area_renderer() should
be created.
- Added gtk_cell_area_aligned_cell_area() to get the aligned
internal area use by a cell (for focus painting and for
event areas).
- Provide the event area in "editing-started" signal
- Fire "remove-editable" when editing is canceled by the user,
an implementing layouting widget need only catch "editing-started"
and "remove-editable" now.
- CellAreaScaffold/testcellarea now edit textrenderers.
Now GtkCellAreaBox handles the click event to activate renderers
and checks if the area is in a sibling of a focus renderer, possibly
activating the proper focus sibling renderer.
Also GtkCellArea gains a "focus-changed" signal to allow it to
change the currently focused row according to the button events.
Added concept of "Focus Siblings" to GtkCellArea so that some
static text/icon may be included in the focus/click area of
an activatable or editable cell, implemented focus drawing
as well, updated testcellarea to reflect the changes.
- Fixed focus driving in GtkCellArea with refined apis
- Added gtk_cell_area_activate() to be called when the area has focus
(to activate or start editing the focused cell)
- Added support for this in cellareascaffold
- testcellarea now watches the "toggled" signal for a toggle renderer
and updates the model state accordingly, this currently works with
keyboard navigation, however focus is still not painted on cells.
Set default directory to G_USER_DIRECTORY_DOCUMENTS
when printing to file backend and fallback to the current
directory when it is not available (#633896).
-removed headers that ceased to exist
-bump API version
-made up for new headers that is to be installed
-gtk-demo program and related sources/data copied to bin/gtk3-demo
Debian changed the behavior of libtool to not follow dependencies
from .la files. Fortunately, the scanner explicitly looks at the
.la files to see if they're really shared; if not it doesn't add
them to the .gir, so there's no cost.
https://bugzilla.gnome.org/show_bug.cgi?id=633405
This is just a private convenience function, and exporting _-prefixed
functions doesn't work with our libtool setup. Just do the 3 line
calculation in gail.
-Made up for the additional dependencies for setups other than Debug|Win32 (the correct setting)
-Made Subsystem="1" for all setups like Debug|Win32 (the correct setting)
-Removed the GdkPixbuf stuff as it is now in a package of its own and added
it as a dependent library here
-Made up for the headers missed in the installation stage for GTK+/GDK
-Made up for the additional dependencies for setups other than Debug|Win32 (the correct setting)
-Made Subsystem="1" for all setups like Debug|Win32 (the correct setting)
-Removed the GdkPixbuf stuff as it is now in a package of its own and added
it as a dependent library here
-Made up for the headers missed in the installation stage for GTK+/GDK
Now when the GtkCellAreaBox receives key events it cycles
the currently focused cell to the next focusable cell in the box
while observing the navigation direction, it then emits "focus-leave"
when hitting the boundries of the area.
Now:
- The current edit cell and editable widget in use can be fetched
with properties and accessors
- gtk_cell_area_activate_cell() handles bookkeeping of the currently
edited cell, starting the editing of a cell, activating a cell etc
- Exported signals are available on GtkCellArea: "editing-started",
"editing-canceled", "editing-done", "remove-editable".
- Upon receiving GDK_KEY_Escape current editing gets canceled.
Windows 7 is managing status icon visibility across process lifetime,
which did not work with GTK+ create icons. Apparently the mechanism
does not require use of new API (like suggested by MSDN), but it is
enough to give a "unique" tooltip at creation time.
Formerly this initial tooltip was not set at all, later setting via
gtk_status_icon_set_tooltip_text() is not enough, but luckily
different follow-up tooltips don't disturb the intended behavior.
(cherry picked from commit ae0544c636)
(cherry picked from commit 8a9d458baf)
Windows 7 is managing status icon visibility across process lifetime,
which did not work with GTK+ create icons. Apparently the mechanism
does not require use of new API (like suggested by MSDN), but it is
enough to give a "unique" tooltip at creation time.
Formerly this initial tooltip was not set at all, later setting via
gtk_status_icon_set_tooltip_text() is not enough, but luckily
different follow-up tooltips don't disturb the intended behavior.
(cherry picked from commit ae0544c636)
(cherry picked from commit 8a9d458baf)
- Added vfunc to get the allocation of a cell inside an area
- Superclass GtkCellArea handles activation of focused cells
by handling key events (as well as editing of editable cells)
- Added signal "editing-started" to GtkCellArea to signal that
editing has started (generally signaled from inside event handling)
- Added properties "focus-cell" and "edited-cell"
CSS3 defines a somewhat odd syntax for rgba() colors - the rgb values
are integers from 0 to 255 or percentages and the a value is a
float from 0 to 1. To avoid increasing the total amount of confusion
in the world, make gdk_rgb_to_string() and gdk_rgb_parse() follow
this syntax rather than using floats for r, g, and b.
https://bugzilla.gnome.org/show_bug.cgi?id=633762
CSS3 defines a somewhat odd syntax for rgba() colors - the rgb values
are integers from 0 to 255 or percentages and the a value is a
float from 0 to 1. To avoid increasing the total amount of confusion
in the world, make gdk_rgb_to_string() and gdk_rgb_parse() follow
this syntax rather than using floats for r, g, and b.
https://bugzilla.gnome.org/show_bug.cgi?id=633762
The state of expanded cells must come from the view, since these states
can vary across views accessing the same model (also "finished up" the
applying of attributes code).
and let GtkContainer do the job; fixes doubled border widths. GtkBox
did already delegate border handling to Gtkcontainer, which interacted
badly with a subclass that didn't.
The custom page type will not show any buttons by default, and
it is left to the application to add its own buttons instead.
The _next_page() and _previous_page() functions can be used
for the back and forward buttons used by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=576498
and let GtkContainer do the job; fixes doubled border widths. GtkBox
did already delegate border handling to Gtkcontainer, which interacted
badly with a subclass that didn't.
The custom page type will not show any buttons by default, and
it is left to the application to add its own buttons instead.
The _next_page() and _previous_page() functions can be used
for the back and forward buttons used by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=576498
The rationale here is that every cell in an area needs to have space
reserved around it, requests have to be fully margin inclusive...
cells need to have the full size fed as the "background area" and
the "cell area" has margins removed... This will be used by GtkTreeViewColumn
to set the focus line width so that cells can paint a background on the
full background, then render themselves into the cell area... and parents
can go ahead and draw focus and other indicators on the background area
but outside of the cell area.
Added get_allocated_cells() which returns a practical list
of cells with allocation for render/event time, this abstracts
whether the cells are individually aligned or aligned into groups,
when there are groups of cells before an alignment, those groups
get allocated on the fly for render time.
Fixed the hangs by adding a ->inside_allocation flag and avoiding to
queue resizes while inside the allocation loop. The extra queue'd resizes
were causing the scrolled window size_allocate() to perform the guess
again and again thus causing an infinite loop.
Seems with GtkScrollable interface we were setting the hadjustment as
the vadjustment, thanks to Cosimo Cecchi who debugged this and finally
found the typo.
Fixed the hangs by adding a ->inside_allocation flag and avoiding to
queue resizes while inside the allocation loop. The extra queue'd resizes
were causing the scrolled window size_allocate() to perform the guess
again and again thus causing an infinite loop.
Seems with GtkScrollable interface we were setting the hadjustment as
the vadjustment, thanks to Cosimo Cecchi who debugged this and finally
found the typo.
Also fixed GtkCellAreaBox to track the iters it creates and flush
them when the overall layout configuration changes (add/remove/reorder/
spacing changed etc).
The core pointer is sort of meaningless in a multidevice environment,
the client pointer is used instead to fake a GdkDevice on events that
don't have one.
GtkButtonBox doesn't do height-for-width, therefore we should
explicitly set these methods to NULL instead of hoping that the
inherited GtkBox implementations work ok.
If the style didn't include symbolic colors for either success,
warning or error, gtk_icon_info_load_symbolic_for_style() would crash.
Instead, make sure we don't try to use the colors if they're not
available, and fallback on default colors inside
_gtk_icon_info_load_symbolic_internal().
Previously any X error from XFixesChangeSaveSet() was being eaten
by the subsequent error trap when sending a client message. With
asynchronous error traps, that side effect no longer occurs, so
we need to add a proper error trap around the call to
XFixesChangeSaveSet().
https://bugzilla.gnome.org/show_bug.cgi?id=633274
This should be implemented as propery height-for-width by
the treeview-refactor branch. This commit includes a FIXME
comment that scroll adjustments should not be updated from
inside size requests but only after receiving an allocation.
The core pointer is sort of meaningless in a multidevice environment,
the client pointer is used instead to fake a GdkDevice on events that
don't have one.
GtkButtonBox doesn't do height-for-width, therefore we should
explicitly set these methods to NULL instead of hoping that the
inherited GtkBox implementations work ok.
If the style didn't include symbolic colors for either success,
warning or error, gtk_icon_info_load_symbolic_for_style() would crash.
Instead, make sure we don't try to use the colors if they're not
available, and fallback on default colors inside
_gtk_icon_info_load_symbolic_internal().
Previously any X error from XFixesChangeSaveSet() was being eaten
by the subsequent error trap when sending a client message. With
asynchronous error traps, that side effect no longer occurs, so
we need to add a proper error trap around the call to
XFixesChangeSaveSet().
https://bugzilla.gnome.org/show_bug.cgi?id=633274
This should be implemented as propery height-for-width by
the treeview-refactor branch. This commit includes a FIXME
comment that scroll adjustments should not be updated from
inside size requests but only after receiving an allocation.
Added the following to GtkCellAreaBox:
- GtkCellAreaBox:spacing property defines spacing between cells
- GtkCellAreaBox:align-cells property defines whether cells should
be aligned with cells in adjacent rows.
- Implementations for get_preferred_width / get_preferred_height
- Implementations for get_preferred_height_for_width and the other
when the box is oriented in the easy way (i.e. height_for_width()
implemented for a vertical box, no virtual allocations done yet).
The interaction between this class and GtkCellAreaBox could
use some optimization, maybe the cells and their sizes should
be returned as a list and iterated over at the same time as
requesting sizes instead of the hash table approach currently
taken, however the code is clean this way for now.
Added base class to hold alignment and overall size request information
while itterating over the size requests of various rows of a GtkTreeModel,
updated GtkCellArea/GtkCellAreaBox classes accordingly.
This patch adds the GtkScrollablePolicy type property to GtkScrollable
and implements it in all subclasses. GtkScrolledWindow observes this
property to make a good guess about when to show/hide scrollbars for
height-for-width content.
Most scrollable children do not do height-for-width *yet* but
most certainly will (toolpalette, treeview, iconview, textview
widgets all TODO), for scrollable widgets that do have a minimum
and natural size, it's important for them to observe the state
of this property in order to properly drive the scroll adjustments
according to the desired GtkScrollablePolicy. This patch makes
GtkViewport do this.
Patch also adds tests/testscrolledwindow.c to display the effects
of this property.
Added the child list to GtkCellAreaBox, added _pack_start() and
_pack_end() apis to GtkCellAreaBox since they are appropriate there
and implemented GtkCellLayoutIface to override the _pack_start()/end()
methods (since the base GtkCellArea class simply forwards these apis
to the generic ->add() api on the base class).
Now GtkCellArea handles attribute connections in the base class,
subclasses only need to add/remove the renderers, render them,
do geometry and handle events.
Now GtkCellArea provides a generic way of applying attributes
from a GtkTreeModel/GtkTreeIter, GtkCellArea bookkeeps a hashtable
of GtkCellLayoutDataFunc's and completely abstracts the applying
of data to cells... GtkCellArea implementations need only to bookkeep
the added renderers and attributes (probably we can abstract the
attribute bookkeeping in the base class as well).
Things starting to take a good and practical shape.
The scrollable patch removed set_scroll_adjustments (NULL, NULL) from
gtk_tree_view_init() which ensured the treeview would have adjustments
at all times, this patch adds set_v/hadjustment (NULL) to _init to ensure
the same thing (without it, there are crashes when trying to access the
adjustments notably from set_headers_visible() in gedit).
I.e. Since we are now calling get_preferred_width() to ensure a good 'for_size'
for get_height_for_width() we need to avoid warning about this internal expected
recursion.
These properties use GdkRGBA to render the cell renderer's content.
Note that Pango attributes are used to render the foreground color,
so the alpha value is currently ignored.
This new function takes a GdkRGBA in order to set the background to
an alpha color. Keep in mind that RGBA visuals and a composited environment
are still necessary to have an alpha background displayed.
GdkRGBA is a boxed struct similar to GdkColor, with the difference
that it stores alpha information as well, and colors are stored in
[0..1] doubles, in the cairo spirit.
gdk_cairo_set_source_rgba() has been also added to allow easier handling
of this new type.
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.
Since the ::changed implementation of GtkRecentManager implies a
synchronous write operation, when we receive multiple requests to emit a
::changed signal we might end up blocking.
This change coalesces multiple ::changed emission requests using the
following sequence:
• the first request will install a timeout in 250 ms, which will
emit the ::changed signal
• each further request while the timeout has not been emitted
will increase a counter
‣ if the counter reaches 250 before the timeout has been
emitted, then the RecentManager will remove the timeout
source and force a signal emission and reset the counter
This sequence should guarantee that frequent ::changed emission requests
are coalesced, and also guarantee that we don't let them dangle for too
long.
https://bugzilla.gnome.org/show_bug.cgi?id=616997
alignment/margin vfuncs adjust_size_request/allocation
Now get_height_for_width() will internally update the for_width
before passing it to the real height_for_width() vfunc, allowing
margins and extra space for alignments to be stripped, thus requesting
sufficient height for greater than natural widths (and also accounting
for margins properly). Test case adjusted in testadjustsize to ensure
proper behavior.
Create a new adjustment if there was *no* adjustment passed in, not
the other way around. Also remove unused function
gtk_tool_palette_set_adjustment().
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
Remove the check for GTK_TREE_MODEL_LIST_ONLY and make the view
display only the first level of the tree, ignoring all insert, remove
etc. events on the model's branches. This enables generic application
code which always produces GtkTreeStores (also for flat lists) to
display grids of these flat trees.
We lookup a widget to call a function on GtkWidget that ends up just
performing an operation directly on the GdkWindow again anyway
(beeping). There's already fallback code at the point of the call that
does exactly that anyway, so just do that all of the time.
- add slots for damage-event, move-focus and keynav-failed
- reorder signals a bit so related stuff is grouped together
- some indentation fixes in the GtkWidgetClass
- remove the move-focus compat hack from GtkTextView
- turn the move-focus compat hack in GtkWindow into properly
implementing GtkWidget::move-focus()
The gtkprivate.h header contains GtkWidget-specific private symbols that
are not useful except in a handful of cases. Basically everything
includes gtkprivate.h for the GTK_PARAM_* macros.
https://bugzilla.gnome.org/show_bug.cgi?id=632539
Some GtkSettings property are registered by other classes. This leads
to the "interesting" issue that setting GtkSettings:gtk-button-images
requires that the GtkButton class is referenced first - or that a
GtkButton is created.
https://bugzilla.gnome.org/show_bug.cgi?id=632538
gcc warns if you switch on values that are not part of the enum you're
switching on. So handle those cases in the default handler by using if
statments.
PS: Someone file a bug against cups about this?
This path would only do anything where widget->window was not located at
widget->allocation.x/y but at a different position. This should never
happen in the real world. But if it does, GTK3 will break for you.
Better fix your widget.
gtk_icon_view_layout(), which can resize the bin window and thus
underlying surfaces, could be called from gtk_icon_view_draw(). So
we have to make sure that layouting is done before the draw handler is
called. We use the same construction as in tree view here, the layout
idle handler is installed with a higher priority than
GDK_PRIORITY_REDRAW and we wrap the call to gdk_window_process_updates()
in a new function that will flush the layout queue beforehand.
This patch adds a GtkComboBox:popup-fixed-width to decide if the
popup's width should be a fixed width matching the combo's allocated width.
The patch includes a kindof hack to work around treeviews currently
not supporting height-for-width geometry (for list-mode only), this
hack can be safely removed once treeviews start reporting natural
widths properly.
After the filechooser got converted to use gsettings, it can no
longer be used uninstalled, breaking make distcheck here.
Also disable the treeview-scrolling tests, since they are failing
here.
Parse options job-sheets, job-hold-until and sides correctly.
Add get_lpoption_name() for translation of lpoption names to
gtk option names. Usable for options which values don't need
conversion (e.g. number-up, number-up-layout, job-billing
and job-priority).
Rename array option_names to ppd_option_names to reflect its
purpose better. Rename get_option_name() to get_ppd_option_name()
because of the same reason.
Allow -1 for the hotspot coordinates in gdk_cursor_new_from_pixbuf,
if the pixbuf contains the x_hot/y_hot options with appropriate values.
Bug #632140.
We build the examples that are included in the 'getting started'
chapter of the docs to prevent them from bitrotting. Also
remove the awk scripts used to extract the old examples from
the tutorial, since the tutorial is gone. I'm still leaving
the examples themeselves in place, for possible inclusion in
'getting started' later on.
We add a "Getting started" chapter that will grow into a
(hopefully) non-outdated, maintained tutorial. For now, it
includes two minimal examples by xincluding them.
We cannot use the GtkButton::clicked signal to override the default
behavior of GtkLinkButton (i.e. call gtk_show_uri()), because
GtkButton::clicked is registered as a RUN_FIRST signal, which obviously
prevents any other signal handler connected to it to stop the
propagation before the class handler has a chance to run.
For this reason we can add a GtkLinkButton::activate-link signal, which
will be emitted by the default GtkButton::clicked signal handler; the
::activate-link signal has a boolean return value, which allows simpler
code for stopping the propagation to the next signal handler.
https://bugzilla.gnome.org/show_bug.cgi?id=632150
Removed portion of scrolled-window that observes user-set
size request data (aux_info->width/height) on the child directly
in order to derive it's minimum possible size... if the scrolled
window has (auto/always) scrollbars in a said orientation; only
request enough space for the scrollbars (bug 631976).
The idea is that it is way more common to want to manipulate the
actual list, rather than the headers. Once you Tab into the treeview
(and the list part gets the focus), you can use Shift-Tab to focus
the headers.
This means that some hysteresis is added to the focus chain, but
it makes the treeview a lot more convenient to focus with the keyboard.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Because validate_visible_area() can modify the window size (and thus
the underlying surface), it should not be called from within the draw
method. Given that the presize handler is run with a higher priority
than redraw, and the presize handler will validate the visible area,
there should not be cases wherein the draw method is called and
validate_visible_area() has not been run yet.
However, one such a case was gdk_window_process_updates(), which would
trigger the draw method at some point. We now work around this
by factoring this in a new gtk_tree_view_bin_process_updates() function
that will run the presize handler first if needed.
Note: for other platforms, it might still be the case that the draw
method is called and validate_visible_area() has not been run yet.
(For example the Mac backend calls gdk_window_process_updates() from
the drawRect method, and the redraw-in-idle handling thus works
differently). This does not seem to be a problem now, if
it will be in the future we need to take care of that then.
This test is constructed in such a way that it breaks when you
(currently!) do not trigger a size-request from validate_visible_area.
Especially row expansion appears to have a need for this currently.
Add signal GdkWindow::create-surface which allows to use any
surface type as storage for offscreen windows.
Test the new signal in tests/gdkoffscreenbox.c
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 expand a tab if either tab-expand is set, or the generic widget
expand property in the correct direction is set. And we do not
propagate expand flags from tab labels to the notebook, only
the expand flags from the pages.
We expand a child when it either has the table-specific expand flag
or the generic expand property set. Override compute_expand so that
it also takes the table-specific expand flags of children into
account.
https://bugzilla.gnome.org/show_bug.cgi?id=628902
This consists of:
* expand a child if either child->expand || gtk_widget_get_expand(child)
* override compute_expand so that child->expand will cause us to
return TRUE for gtk_widget_get_expand()
https://bugzilla.gnome.org/show_bug.cgi?id=628902
There are two colored boxes with toggle buttons nested
inside several GtkBox. Toggling these to expand mode
should automatically propagate expansion up through
the several GtkBox such that resizing the window
results in resizing the colored boxes.
https://bugzilla.gnome.org/show_bug.cgi?id=628902
GtkWidget now has flags for horizontal and vertical expand, and
a compute_expand() method. compute_expand() is used by containers
to set a default expand flag. (If a widget has expand set explicitly,
it always overrides the results of compute_expand.)
GtkContainer has a default implementation of compute_expand which
simply walks over all child widgets and sets expand=TRUE
if any child is expanding.
The overall effect is that you only have to set expand on
leaf nodes in the widget tree, while previously you had to
set expand all the way up the tree as you packed every
container. Also, now containers need not have their own child
properties for expand.
For old containers which do have "expand" child properties,
they should override compute_expand and include the child
properties in whether the container is expand=TRUE.
Also, the old container should use
"child_prop_expand || gtk_widget_compute_expand()" everywhere
it previously used simply "child_prop_expand"
https://bugzilla.gnome.org/show_bug.cgi?id=628902
Safe space in the private struct, always set the cursor when we
update visibility, since the cursor depends on resizability conditions
too. And don't set the shape needlessly.
This was caused by get_drag_edge() returning -1 to mean 'no drag',
but callers didn't really pay attention. Change get_drag_edge()
to return a boolean instead.
Call gtk_tree_view_set_cursor() in addition to
gtk_tree_selection_select_iter() when selecting the file in
show_and_select_files() so the preview update machinery gets
triggered.
(cherry picked from commit 795c8070db)
This patch makes the scrolled window reconsider allocating the child
the full width or height (depending on the child's request mode) without
a scrollbar. For instance when the child is height-for-width; the child
will first be tested if the content's height for full allocated width
(without a vscrollbar) will allow the contents height for that width
to fit the allocated height.
Patch is a simplified version of code inspected in st-scroll-view.c.
Note that this patch assumes children will begin to scroll only after
reaching their minimum size; adding a property to the future
GtkScrollableIface to decide whether to scroll-to-minimum or scroll-to-natural
will effect this code (it should then reconsider whether the child
will scroll below the natural size instead of the minimum).
Patch addresses bug 629778.
If you set a geometry widget via gtk_window_set_geometry_hints() it
becomes very hard to compute appropriate toplevel sizes in pixels
to make the window a particular size. Synthesizing strings and passing
them to gtk_window_parse_geometry() is possible, but to avoid
avoid such ugliness, add functions:
gtk_window_set_default_geometry()
gtk_window_resize_to_geometry()
That act like gtk_window_set_default_size() and
gtk_window_resize() but are in terms of the resize increments of the
geometry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=631796
gtk_window_parse_geometry() gets the size of the window in order
to interpret the position of the window; calling it before, say,
calling gtk_widget_show_all() on a window is a subtle trap, so
add a warning in the case we can easily detect.
https://bugzilla.gnome.org/show_bug.cgi?id=631794
The geometry widget feature of gtk_window_set_geometry_hints() has
never really worked right because the calculation that GTK+ did to
compute the base size of the window only worked when the geometry
widget had a larger minimum size than anything else in the window.
Setup:
* Move the GtkSizeGroup private functions to a new private header
gtksizegroup-private.h
* Add the possibilty to pass flags to _gtk_size_group_queue_resize(),
with the flag GTK_QUEUE_RESIZE_INVALIDATE_ONLY to suppress adding
the widget's toplevel to the resize queue.
* _gtk_container_resize_invalidate() is added to implement that feature
* _gtk_widget_override_size_request()/_gtk_widget_restore_size_request()
allow temporarily forcing a large minimum size on the geometry
widget without creating resize loops.
GtkWindow:
* Compute the extra width/height around the geometry widget
correctly; print a warning if the computation fails.
* Always make the minimum size at least the natural minimum
size of the toplevel; GTK+ now fails badly with underallocation.
* Always set the base size hint; we were failing to set it
properly when the specified minimum size was overriden, but
it's harmless to always set it.
Tests:
* New test 'testgeometry' that replaces the 'gridded geometry' test
from testgtk. The new test is roughly similar but creates a bunch
of windows showing different possibilities.
* The testgtk test is removed. No need to have both.
https://bugzilla.gnome.org/show_bug.cgi?id=68668
1,936 (112 direct, 1,824 indirect) bytes in 4 blocks are definitely lost in loss record 13,453 of 13,673
at 0x4005BDC: malloc (vg_replace_malloc.c:195)
by 0x69615A1: cairo_region_create (cairo-region.c:196)
by 0x683BFBF: gdk_cairo_region_create_from_surface (gdkcairo.c:455)
by 0x670C882: set_grip_shape (gtkwindow.c:5020)
by 0x670CFBF: resize_grip_create_window (gtkwindow.c:5271)
by 0x670C466: gtk_window_realize (gtkwindow.c:4902)
Signed-off-by: Benjamin Otte <otte@redhat.com>
1,968 (1,236 direct, 732 indirect) bytes in 1 blocks are definitely lost in loss record 11,816 of 11,947
at 0x4025BDC: malloc (vg_replace_malloc.c:195)
by 0x6950676: _context_get (cairo.c:250)
by 0x6950940: cairo_create (cairo.c:370)
by 0x685CD1E: _gdk_cairo_surface_extents (gdkcairo.c:381)
by 0x685CEDA: gdk_cairo_region_create_from_surface (gdkcairo.c:433)
Signed-off-by: Benjamin Otte <otte@redhat.com>
We need to be a little more careful when determining the overlap
between the new allocation and the grip area. This was causing
vertical scrollbars in evince to overlap with the grip.
This is safer, since GtkWindow subclasses may override realize
and end up with has_resize_grip == TRUE, but grip_window still
being NULL - as is the case with GtkPlug.
We need to position the grip window in size_allocate after all,
otherwise the grip ends up in the wrong place when the window
is realized early.
Also, avoid shadowing a variable.
This was another case of making sure size-request was called
before other code was doing get_child_requisition(), now caching
is done via the same api so no need for that line.
Old code was probably doing size-request on all children initially,
and then calling get_child_requisition() in other passes, now these
are cached after the first request anyway.
If there are both horizontal and vertical scrollbars, there is
an unused 'corner' into which the resize grip fits. Individual
scrollbars need to be shortened and moved to make room for the
resize grip.
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.
If you type 'subfolder/' and hit Enter, the file chooser will switch you to
it. But if you type just 'subfolder' without the trailing slash, apps would
receive *that* filename (e.g. file:///foo/bar/subfolder) as the response, and
they would likely print an error that they can't open that file (as it is
a folder). So, we change the file chooser's current folder to that subfolder
in this case.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Previously name_entry_get_parent_info_cb() would fail as it doesn't handle SELECT_FOLDER.
Now we just make that function act the same as for CREATE_FOLDER mode. In either
case, if you type "/blah/nonexistent" and hit Enter, you want a folder
with that name to be created (under the already-existing /blah).
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The old save_entry_get_info_cb() was misnamed; it is actually used
to see if a file's presumed parent *is* a folder. So we rename
it to name_entry_get_parent_info_cb().
Signed-off-by: Federico Mena Quintero <federico@novell.com>
file_exists_get_info_cb() used to let some actions fall through to
the code that checks for the file type of the selected file's parent
(e.g. to see if /foo/bar *is* indeed a folder if you type /foo/bar/baz).
However, we need to be more explicit for each file chooser action, as
in SELECT_FOLDER mode typing /foo/foldername and hitting Enter would not
give you an immediate selection, but rather the file chooser would
complain that it couldn't create that directory as it already exists.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
We subclass GdkWindowImplQuartz into a new GdkRootWindowImplQuartz,
and override the get_context method in order to do this cleanly.
Also made release_context a virtual method, since the root window has
to release its CGContextRef differently compared to normal windows.
The ownership of the return value for gdk_pixbuf_get_from_window() and
gdk_pixbuf_get_from_surface() was determined by the first argument.
Because that is an ugly design and the functions are new to GTK3, we
decided to adapt them.
And that adaptation was quite easy since almost no one passses anything
but NULL as the first argument.
This previously caused the x11 code to do a XSetWindowBackgroundPixmap
call on a window that was about to be destroyed. And that's not really
useful.
https://bugzilla.gnome.org/show_bug.cgi?id=630864
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.
gtk_paint_layout is utterly broken. Someone needs to fix it so we use
the cairo_t's matrix and don't juggle with both Pango and cairo matrices
everywhere.
When fitting a widget into its allocation, the second dimension
is always dependent on the first, so gtk_widget_get_preferred_size()
cannot be used directly (because we want the natural height for
the allocated width, not the natural height for the natural width,
which is generally a smaller height than the height-for-minimum-width
or height-for-allocated-width).
Added test to testadjustsize to ensure proper behaviour.
This commit add some text about mult-window ::draw implementations,
pointing out the gtk_cairo_should_draw_window() and
gtk_cairo_transform_to_window() convenience functions.
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.
This mostly goes to keep consistency with the changes to GtkSizeRequest
in the last patch, as GtkCellSizeRequest requires GtkCellRenderer and
GtkCellRenderer implements GtkCellSizeRequest there's no use in keeping
them separate.
This patch renames the functions:
gtk_cell_size_request_get_request_mode()
=> gtk_cell_renderer_get_request_mode()
gtk_cell_size_request_get_width()
=> gtk_cell_renderer_get_preferred_width()
gtk_cell_size_request_get_height()
=> gtk_cell_renderer_get_preferred_height()
gtk_cell_size_request_get_size()
=> gtk_cell_renderer_get_preferred_size()
gtk_cell_size_request_get_width_for_height()
=> gtk_cell_renderer_get_preferred_width_for_height()
gtk_cell_size_request_get_height_for_width()
=> gtk_cell_renderer_get_preferred_height_for_width()
... and moves the corresponding vfuncs to GtkCellRenderer.
The patch also renames the implementations of these functions in cell
renderers to include the word "preferrred".
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 feature can and should be implemented manually using
gdk_window_get_background() and Cairo drawing. A non-cairo drawing API
does not make sense in GDK anymore.
I don't think it's necessary to clear the backing surface when showing
the window, as we're going to repaint it anyway. If it's needed, we can
implement it again using internal APIs, as the public window_clear()
APIs are going away.
Previously, we tried to move the context's origin to the widget's top
left location, no matter what window the paint was happening on. Now we
only do that for child windows of the widget's window and leave the
context untouched for windows that the widget has created outside its
own hierarchy. In those casses, we also don't clip the context to
the widget's allocation.
Includes fixes to GtkHandlebox for this effect and fixes all known
issues with it.
These semantics assume that gtk_widget_draw() should only draw the parts
of a widget that are inside child windows and not draw stuff that is
located in completely different GdkWindows. In the handlebox case, it
means that it should only draw the handle when it is attached, but not
when it isn't. We'll likely need a special draw function for the
detached handlebox if we want to draw it.
I've seen (and written) quite some widgets (and theme engines) that use
cairo_paint() to draw the background. So avoiding overdraw makes sense.
Also move all that setup into a _gtk_widget_draw_internal() function
that will be used by all functions that can be used by other functions
that draw widgets.
1) Don't directly draw in motion-notify, instead call
gtk_widget_queue_draw()
2) Don't draw ticks in expose events anymore, only when they were
changed
For now, the draw signal is emitted by default from the expose event, so
widgets can chose to either implement the expose event or the draw
function.
This is for the transitional period from expose event to draw signal.
Note that for now subclasses can only implement the draw function when
none of their parents implemented the expose event.
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).
validate_visible_area() can change the vertical adjustment and thus
trigger window moves/scrolls. This seems to change the surface for
which gtk_tree_view_bin_expose() just created a cairo context. Creating
the cairo context after the call to validate_visible_area() fixes
such crashes.
In particular, the following functions are gone:
- gdk_screen_get_default_colormap()
- gdk_screen_set_default_colormap()
- gdk_screen_get_system_colormap()
- gdk_screen_get_rgba_colormap()
This way, we can specify a colormap when constructing windows. And ew
must do that to avoid BadMatch from XCreateWindow when we use a
different visual.
Also add a priv pointer to GdkVisual and use it for the GdkVisualPrivate
structure. Then Make GdkVisualPrivate actually private to
gdkvisual-x11.c and make other callers use proper function calls to
access it.
Direct and TrueColor visuals don't alloc colors, so they don't need to
fiddle with colormaps. Just copy the code that computes the pixel value
from gdkcolor-x11.c and use it. For other visual types, don't set the
background color and fallback to background = None.
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.
Add gtk_window_set_visual() and a "visual" property. This allows
changing the window visual to the rgba one and other awesome things
(like implementing the trayicon spec).
We now return the visual of the topmost widget in widget's stack that
has a window. If no such widget exists, but a GtkWindow is a parent, we
return its visual (note: GtkWindow Will gain support for setting visuals
soon). If a window doesn't exist, we return the system visual of the
default screen.
This change has multiple reasons:
- Colormaps are gone
Now visuals are the most important resource for creating GDK windows.
- Allow widgets to change visuals for themselves and their children
By walking the hierarchy, we ensure that child windows have the same
visual as their parents by default. But widgets can still select a
different visual in their realize handler when creating the GDK
window.
- Have a replacement for gtk_widget_set_colormap()
That function is going to die with colormaps, so a replacement was
needed. That replacement is going to be gdk_window_set_visual().
- Make a future transition to no-window GTK easy
Should we ever attempt a change to make all GTK widgets no-window, a
gtk_widget_set_visual() would be silly, as only widgets with windows
can have their own visuals. So only toplevels will gain the ability to
change it.
Now that we don't create pixmaps anymore, this function is not needed
anymore. The indirection it did previously is now basically moved to
gdk_window_create_similar_surface()
The 3 functions in question were:
- gdk_pixbuf_render_threshold_alpha()
- gdk_pixbuf_render_pixmap_and_mask()
- gdk_pixbuf_render_pixmap_and_mask_for_colormap()
All of them can be replaced using Cairo if they have to. The
functionality is only needed to talk to old X interfaces and normal apps
do fine without them.
No more GdkPixmap to store the icon and its mask, but instead use cairo
surfaces. Also render the icon into the surfaces using Cairo instead of
gdk_pixbuf_render_threshold_alpha().
With Cairo 1.10 now having cairo_surface_create_for_rectangle(), we can
use them. No need to create multiple native surfaces for the same X
window (ugh) anymore.
The notion of a source drawable does not make a lot of sense for windows
that are not backed by a drawable, such as GdkOffscreenWindow after
converting it to cairo_surface_t.
gtk_widget_get_snapshot is on its way out.
The test can be added back once we have gtk_widget_draw(), but until
then, there's no way to take snapshots.
For now just add it instead of replacing the current function. In the
end, this one should probably be renamed to
gtk_draw_insertion_cursor() and the current
gtk_draw_insertion_cursor() should die.
Now the window background is a cairo_pattern_t. The backends will try to
set this as good as they can on the windowing system, but no guarantees
are made on wether the windowing system supports the pattern.
Also gets rid of GDK_NO_BG as undefined behavior is not a good idea to
support, and GDK_NO_BG effectively made the window's contents undefined.
It wasn't effectively used in GTK anyway.
This removes gdk_window_shape_combine_mask() and
gdk_window_input_shape_combine_mask(). GdkBitmap is going away and a
replacement exists via the combine_region() functions and
gdk_cairo_region_create_from_surface().
Replace gtk_widget_shape_combine_region() with
gtk_widget_shape_combine_mask() and
gtk_widget_input_shape_combine_region() with
gtk_widget_input_shape_combine_mask().
As GdkBitmap is going away, and the region equivalents already exist,
this seems like pretty much the default step to take.
Includes code to fix up the users.
The function converts the given surface into an alpha bitmap mask. This
is mostly useful for setting shape regions.
Also adds a new internal function _gdk_cairo_surface_extents() that
computes a surface's extents.
Basically copies the code for setting the WM icon hint from GtkWindow to
GdkWindow. This achieves the following:
- Putting this X11 specific code into the X11 backend
- Enables removal of gdk_window_set_icon()
- Gets rid of Pixmap/Bitmap usage outside of GDK.
Dealing with bare pointers is problematic for language bindings,
using interned strings is much more straightforward and more than
good enough for what is needed here.
http://bugzilla.gnome.org/show_bug.cgi?id=630521
Problems were; in FREE mode there was a simple typo where we were
repeatedly checking the size of the same item in get_largest_line_length(),
and in ALIGNED mode we were assuming something like HOMOGENEOUS which
was incorrect; added get_largest_aligned_line_length() which properly
adds up the collective max sizes of every index in the line.
With gtk_show_uri, global configurability of link activation has
moved to GIO/gvfs. For local overrides, GtkLinkButton has the ::clicked
signal, and GtkAboutDialog gets an ::activate-link signal.
Bug 339745
Make GtkViewport calculate widget-for-height as well as height-for-width
cases when setting the scroll adjustment values, also base the scrolling
on the minimum size instead of the natural size in the interest of showing
as much content as possible when the viewport is smaller than the natural
size.
trap->end_sequence is the first serial for which we don't
ignore errors anymore, so we know the trap is dead if
end_sequence <= processed_serial.
Bug 629608
Now GtkWrapBox has "horizontal-spreading" and "vertical-spreading" options,
before GtkWrapBox never spread out children across the opposing orientation
(i.e. it never grew "lines" larger then their natural width, they would
act as if set to GTK_WRAP_BOX_SPREAD_START, now they are completely configurable).
Currently fprintf(stderr, ...) is used for X error and X IO errors
(unless compiled with debugging, in which case g_error() is used for
X errors.)
But if an application is redirecting log messages, we really want
X errors to appear in that same log, so it's better to use a g_logv()
variant.
Though g_warning() isn't really appropriate for "lost connection to the
server", G_LOG_LEVEL_INFO isn't part of the "prefixed log levels"
so will produce output without the application name and PID.
https://bugzilla.gnome.org/show_bug.cgi?id=630216
This patch changes the 'age' counting previous approach taken
verbatim from clutter and changes it for a counter of validated
caches and an index to the last cached value which we use to
round-robin through the cache if ever a widget is requested
for more than 3 contextual sizes (cache is reduced by 3 * sizeof (int)
per widget private data).
When an error occurs with nested traps in place, only the innermost
trap should have the error code stored in it; outer traps are
shielded by the inner trap.
https://bugzilla.gnome.org/show_bug.cgi?id=629608
We were trying to avoid selecting a label initially, but the code
was sometimes leaving labels selected when the focus eventually
ended up on a button instead.
* don't lose track of previous X error handler
if nested traps are pushed
* free any remaining traps when display
is finalized
Test will fail unless bug 630032 is closed so
gdk_display_close() works.
https://bugzilla.gnome.org/show_bug.cgi?id=630033
* _gdk_device_set_associated_device() did not allow NULL device
* GdkDisplay should dispose device manager to avoid devices
trying to touch the display in finalize
* GdkDeviceManagerXI did not ref devices in id hash
* GdkDisplayX11 did not ref devices in ->input_devices
* add per-display gdk_x11_display_error_trap_push()
(X11-specific because gdk_error_trap_push() probably
should have been)
* make gdk_error_trap_push() handle only GDK displays
not displays opened without a GDK wrapper
* make gdk_error_trap_pop() and gdk_x11_display_error_trap_pop()
automatically sync only if needed, so manual gdk_flush() is not
required
* add gdk_error_trap_pop_ignored() which just asynchronously
ignores errors, so never needs to sync
* add G_GNUC_WARN_UNUSED_RESULT to plain pop(), because
if you use plain pop() and don't need the return value,
the async gdk_error_trap_pop_ignored() should be used
instead. This results in lots of warnings to clean
up in a later patch.
The main objective here was to avoid the need to sync just
to ignore an error. Now, syncing is automatic, and only
happens when we need to know the error code.
https://bugzilla.gnome.org/show_bug.cgi?id=629608
This was added to the test only for the sake of making it
easier to reproduce a bug with scrolled windows (bug 629778).
Expected behaviour: The vertical scrollbar should dissapear as soon
as the required height for the full allocation width (without any
vertical scrollbar) is small enough to not need a scrollbar.
Seems commit 7b42d4feda makes
GtkSpinner a direct subclass of GtkWidget but forgets to
update the header file to include gtkwidget.h instead and
declare the instance and class structures properly (assuming
this was just a missed file in the commit).
When grouping height-for-width trading widgets (wrapping labels for instance)
vertically; the height for the minimum width will always be used for the entire
group... this patch warns about this in the docs.
Originally the GtkSizeRequestIface patches left GtkSizeGroup working
only by bumping the minimum sizes - this commit fixes size groups to take
both minimum and natural requests into account.
Since the location button is hidden in save mode, we need to add the
path bar to the size group too. The location button still has to be in
the group though, because it's larger than the path bar (when
shown). Instead of using the recent/search icons, add their hboxes so
that themed widget spacings don't introduce variations.
With this new approach at request and allocate time, the average child size
is used to determine a good guess at how many columns will fit the box
width; afterwards extra columns are appended and checked to fit.
Then the row heights are calculated based on height-for-width of each
child in the row which now may have individual widths.
Add the composite overlay window to the cache, as this can be a reasonable Xdnd proxy as well.
This is only done when the screen is composited in order to avoid mapping
the COW. We assume that the CM is using the COW (which is true for pretty
much any CM currently in use).
https://bugzilla.gnome.org/show_bug.cgi?id=601731
The detail strings now have more "detail" by default, so gtkstyle.c
needed to be updated to properly handle this. Tests like testtreeview,
testtreesort now have proper background drawing again.
This strncmp trick was the best I could think of so quickly, if anybody
has an idea to do this in a better way, let me know.
h-align = START,END,CENTER,FILL
v-align = START,END,CENTER,FILL
margin-left,right,top,bottom
margin
These should obsolete all such similar properties on
layout containers, GtkMisc, GtkAlignment, GtkContainer::border-width
Margin is outside the size request.
If margin were not outside the set_size_request() it would not work the
same way as container-supplied (child property) padding.
Conceptually set_size_request() forces the value from the subclass
(the original unadjusted request) and then we go on to adjust
the request further by adding the margin.
A subclass calls gtk_container_class_handle_border_width()
in its class_init
This marks the subclass as expecting GtkContainer to deal with
border width automatically, which GtkContainer then does.
Use these new methods to handle set_size_request (aka aux_info)
inside gtkwidget.c, instead of having external code mess with it.
The virtual functions can be used for other purposes in the
future. For example, GtkContainer::border_width could be
automatically implemented for all container subclasses.
Did not update uses in other files because the plan is to
get rid of those other uses anyhow. So don't want to make
this function available in the header.
This is better than peeking aux info then testing != NULL
in several ways:
- it returns const aux info so if we don't create we can't write
- it ensures that the default we assume if aux_info is NULL is
the same as the default we set if we've created the aux info
- it avoids typing in != NULL checks
We are not re-entrant and there is no reason for widgets to
do this, most likely they'll just get unexpected bugs because
the wrappers may modify the request.
Computing the request should logically rely only on the
widget itself, not on any adjustments caused by set_size_request,
size groups, and so forth.
https://bugzilla.gnome.org/show_bug.cgi?id=628829
In GtkBin and GtkWidget we tried to provide handy defaults that
call get_width if there's no get_width_for_height and
get_height for get_height_for_width.
However, they used the wrapper API on GtkSizeRequest instead of
chaining directly to the other method implementation.
This could result in all kinds of surprising behavior, for example,
get_width_for_height() would now already include the effects of set_size_request().
If nothing else it's inefficient. But it's just conceptually wrong,
because to chain to another implementation, we should call the other
implementation, not call a wrapper around the other implementation
(when we're already inside a previous invocation of the wrapper,
i.e. compute_size_for_orientation() ends up reinvoking itself
in the same orientation on the same object which it pretty
likely isn't intending to do)
https://bugzilla.gnome.org/show_bug.cgi?id=628829
32K of border ought to be enough for any pixel dimensions. At least
until screens are so huge we start using doubles.
This saves a nice 64 bits of space when we have a GtkBorder
stored somewhere.
Signed integers are used to avoid surprising unsigned math
issues. Just search GTK's whole git log from inception
for "unsigned" if you want to find any number of commits
fixing signed/unsigned bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=629387
When writing the original code I erroneously assumed that the current
point of the cairo context would be saved by cairo_save/restore(), but
of course the current point is part of the path and therefor isn't
saved.
Also do a cairo_new_path() before rendering any text so that we are sure
the text ends up at the right spot.
2010-09-12 16:00:05 +02:00
1373 changed files with 458174 additions and 580125 deletions
gtk_text_buffer_insert(buffer,&iter,"The text widget can display text with all kinds of nifty attributes. It also supports multiple views of the same buffer; this demo is showing the same buffer in two places.\n\n",-1);
gtk_text_buffer_insert(buffer,&iter,
"The text widget can display text with all kinds of nifty attributes. "
"It also supports multiple views of the same buffer; this demo is "
"You can also adjust the amount of space between wrapped lines; this line has extra space between each wrapped line in the same paragraph. To show off wrapping, some filler text: the quick brown fox jumped over the lazy dog. Blah blah blah blah blah blah blah blah blah.\n",-1,
"double_spaced_line","wide_margins",NULL);
gtk_text_buffer_insert(buffer,&iter,"Also note that those lines have extra-wide margins.\n\n",-1);
"This line (and most of the others in this buffer) is word-wrapped, using the proper Unicode algorithm. Word wrap should work in all scripts and languages that GTK+ supports. Let's make this a long paragraph to demonstrate: blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah\n\n",-1);
"This line has character-based wrapping, and can wrap between any two character glyphs. Let's make this a long paragraph to demonstrate: blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah\n\n",-1,
"\nThis line has big wide margins. Text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text.\n",-1,
"wide_margins",NULL);
"You can also adjust the amount of space between wrapped lines; "
"this line has extra space between each wrapped line in the same "
"paragraph. To show off wrapping, some filler text: the quick "
"brown fox jumped over the lazy dog. Blah blah blah blah blah "
"You can put all sorts of Unicode text in the buffer.\n\nGerman (Deutsch S\303\274d) Gr\303\274\303\237 Gott\nGreek (\316\225\316\273\316\273\316\267\316\275\316\271\316\272\316\254) \316\223\316\265\316\271\316\254\317\203\316\261\317\202\nHebrew \327\251\327\234\327\225\327\235\nJapanese (\346\227\245\346\234\254\350\252\236)\n\nThe widget properly handles bidirectional text, word wrapping, DOS/UNIX/Unicode paragraph separators, grapheme boundaries, and so on using the Pango internationalization framework.\n",-1);
"Also note that those lines have extra-wide margins.\n\n",-1);
gtk_text_buffer_insert(buffer,&iter,"Here's a word-wrapped quote in a right-to-left language:\n",-1);
gtk_text_buffer_insert(buffer,&iter,"\n\nThis demo doesn't demonstrate all the GtkTextBuffer features; it leaves out, for example: invisible/hidden text, tab stops, application-drawn areas on the sides of the widget for displaying breakpoints and such...",-1);
gtk_text_buffer_insert(buffer,&iter,
"\n\nThis demo doesn't demonstrate all the GtkTextBuffer features; "
"it leaves out, for example: invisible/hidden text, tab stops, "
"application-drawn areas on the sides of the widget for displaying "
Key values are the codes which are sent whenever a key is pressed or released.
They appear in the <structfield>keyval</structfield> field of the
#GdkEventKey structure, which is passed to signal handlers for the
"key-press-event" and "key-release-event" signals.
The complete list of key values can be found in the <filename><gdk/gdkkeysyms.h></filename>
header file.
</para>
<para>
Key values are regularly updated from the upstream X.org X11 implementation,
so new values are added regularly. They will be prefixed with GDK_KEY_ rather
than XF86XK_ or XK_ (for older symbols).
</para>
<para>
Key values can be converted into a string representation using
gdk_keyval_name(). The reverse function, converting a string to a key value,
is provided by gdk_keyval_from_name().
</para>
<para>
The case of key values can be determined using gdk_keyval_is_upper() and
gdk_keyval_is_lower(). Key values can be converted to upper or lower case
using gdk_keyval_to_upper() and gdk_keyval_to_lower().
</para>
<para>
When it makes sense, key values can be converted to and from
Unicode characters with gdk_keyval_to_unicode() and gdk_unicode_to_keyval().
</para>
<para id="key-group-explanation">
One #GdkKeymap object exists for each user display. gdk_keymap_get_default()
returns the #GdkKeymap for the default display; to obtain keymaps for other
displays, use gdk_keymap_get_for_display(). A keymap
is a mapping from #GdkKeymapKey to key values. You can think of a #GdkKeymapKey
as a representation of a symbol printed on a physical keyboard key. That is, it
contains three pieces of information. First, it contains the hardware keycode;
this is an identifying number for a physical key. Second, it contains the
<firstterm>level</firstterm> of the key. The level indicates which symbol on the
key will be used, in a vertical direction. So on a standard US keyboard, the key
with the number "1" on it also has the exclamation point ("!") character on
it. The level indicates whether to use the "1" or the "!" symbol. The letter
keys are considered to have a lowercase letter at level 0, and an uppercase
letter at level 1, though only the uppercase letter is printed. Third, the
#GdkKeymapKey contains a group; groups are not used on standard US keyboards,
but are used in many other countries. On a keyboard with groups, there can be 3
or 4 symbols printed on a single key. The group indicates movement in a
horizontal direction. Usually groups are used for two different languages. In
group 0, a key might have two English characters, and in group 1 it might have
two Hebrew characters. The Hebrew characters will be printed on the key next to
the English characters.
</para>
<para>
In order to use a keymap to interpret a key event, it's necessary to first
convert the keyboard state into an effective group and level. This is done via a
set of rules that varies widely according to type of keyboard and user
configuration. The function gdk_keymap_translate_keyboard_state() accepts a
keyboard state -- consisting of hardware keycode pressed, active modifiers, and
active group -- applies the appropriate rules, and returns the group/level to be
used to index the keymap, along with the modifiers which did not affect the
group and level. i.e. it returns "unconsumed modifiers." The keyboard group may
differ from the effective group used for keymap lookups because some keys don't
have multiple groups - e.g. the Enter key is always in group 0 regardless of
keyboard state.
</para>
<para>
Note that gdk_keymap_translate_keyboard_state() also returns the keyval, i.e. it
goes ahead and performs the keymap lookup in addition to telling you which
effective group/level values were used for the lookup. #GdkEventKey already
contains this keyval, however, so you don't normally need to call
gdk_keymap_translate_keyboard_state() just to get the keyval.
</para>
<!-- ##### SECTION See_Also ##### -->
<para>
</para>
<!-- ##### SECTION Stability_Level ##### -->
<!-- ##### SECTION Image ##### -->
<!-- ##### STRUCT GdkKeymap ##### -->
<para>
A <structname>GdkKeymap</structname> defines the translation from keyboard state
(including a hardware key, a modifier mask, and active keyboard group)
to a keyval. This translation has two phases. The first phase is
to determine the effective keyboard group and level for the keyboard
state; the second phase is to look up the keycode/group/level triplet
in the keymap and see what keyval it corresponds to.
</para>
<!-- ##### SIGNAL GdkKeymap::direction-changed ##### -->
<para>
</para>
@keymap: the object which received the signal.
<!-- ##### SIGNAL GdkKeymap::keys-changed ##### -->
<para>
</para>
@keymap: the object which received the signal.
<!-- ##### SIGNAL GdkKeymap::state-changed ##### -->
<para>
</para>
@gdkkeymap: the object which received the signal.
<!-- ##### STRUCT GdkKeymapKey ##### -->
<para>
A <structname>GdkKeymapKey</structname> is a hardware key that can
be mapped to a keyval.
</para>
@keycode: the hardware keycode. This is an identifying number for a
physical key.
@group: indicates movement in a horizontal direction. Usually groups are used
for two different languages. In group 0, a key might have two English
characters, and in group 1 it might have two Hebrew characters. The Hebrew
characters will be printed on the key next to the English characters.
@level: indicates which symbol on the key will be used, in a vertical direction. So on a standard US keyboard, the key with the number "1" on it also has the
exclamation point ("!") character on it. The level indicates whether to use
the "1" or the "!" symbol. The letter keys are considered to have a lowercase
letter at level 0, and an uppercase letter at level 1, though only the
uppercase letter is printed.
<!-- ##### FUNCTION gdk_keymap_get_default ##### -->
<para>
</para>
@void:
@Returns:
<!-- ##### FUNCTION gdk_keymap_get_for_display ##### -->
<para>
</para>
@display:
@Returns:
<!-- ##### FUNCTION gdk_keymap_lookup_key ##### -->
<para>
</para>
@keymap:
@key:
@Returns:
<!-- ##### FUNCTION gdk_keymap_translate_keyboard_state ##### -->
<para>
</para>
@keymap:
@hardware_keycode:
@state:
@group:
@keyval:
@effective_group:
@level:
@consumed_modifiers:
@Returns:
<!-- ##### FUNCTION gdk_keymap_get_entries_for_keyval ##### -->
<para>
</para>
@keymap:
@keyval:
@keys:
@n_keys:
@Returns:
<!-- ##### FUNCTION gdk_keymap_get_entries_for_keycode ##### -->
<para>
</para>
@keymap:
@hardware_keycode:
@keys:
@keyvals:
@n_entries:
@Returns:
<!-- ##### FUNCTION gdk_keymap_get_direction ##### -->
<para>
Returns the direction of the keymap.
</para>
@keymap: a #GdkKeymap or %NULL to use the default keymap.
Returns: %PANGO_DIRECTION_LTR or %PANGO_DIRECTION_RTL.
@Returns: the direction of the keymap.
<!-- ##### FUNCTION gdk_keymap_have_bidi_layouts ##### -->
<para>
</para>
@keymap:
@Returns:
<!-- ##### FUNCTION gdk_keymap_get_caps_lock_state ##### -->
<para>
</para>
@keymap:
@Returns:
<!-- ##### FUNCTION gdk_keymap_get_num_lock_state ##### -->
<para>
</para>
@keymap:
@Returns:
<!-- ##### FUNCTION gdk_keymap_add_virtual_modifiers ##### -->
<para>
</para>
@keymap:
@state:
<!-- ##### FUNCTION gdk_keymap_map_virtual_modifiers ##### -->
<para>
</para>
@keymap:
@state:
@Returns:
<!-- ##### FUNCTION gdk_keyval_name ##### -->
<para>
Converts a key value into a symbolic name.
The names are the same as those in the <filename><gdk/gdkkeysyms.h></filename> header file
but without the leading "GDK_KEY_".
</para>
@keyval: a key value.
@Returns: a string containing the name of the key, or %NULL if @keyval is not
a valid key. The string should not be modified.
<!-- ##### FUNCTION gdk_keyval_from_name ##### -->
<para>
Converts a key name to a key value.
</para>
@keyval_name: a key name.
@Returns: the corresponding key value, or %GDK_VoidSymbol if the key name is
not a valid key.
<!-- ##### FUNCTION gdk_keyval_convert_case ##### -->
<para>
</para>
@symbol:
@lower:
@upper:
<!-- ##### FUNCTION gdk_keyval_to_upper ##### -->
<para>
Converts a key value to upper case, if applicable.
</para>
@keyval: a key value.
@Returns: the upper case form of @keyval, or @keyval itself if it is already
in upper case or it is not subject to case conversion.
<!-- ##### FUNCTION gdk_keyval_to_lower ##### -->
<para>
Converts a key value to lower case, if applicable.
</para>
@keyval: a key value.
@Returns: the lower case form of @keyval, or @keyval itself if it is already
in lower case or it is not subject to case conversion.
<!-- ##### FUNCTION gdk_keyval_is_upper ##### -->
<para>
Returns %TRUE if the given key value is in upper case.
</para>
@keyval: a key value.
@Returns: %TRUE if @keyval is in upper case, or if @keyval is not subject to
case conversion.
<!-- ##### FUNCTION gdk_keyval_is_lower ##### -->
<para>
Returns %TRUE if the given key value is in lower case.
</para>
@keyval: a key value.
@Returns: %TRUE if @keyval is in lower case, or if @keyval is not subject to
case conversion.
<!-- ##### FUNCTION gdk_keyval_to_unicode ##### -->
<para>
</para>
@keyval:
@Returns:
<!-- ##### FUNCTION gdk_unicode_to_keyval ##### -->
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
