Years ago, when the location entry only appeared in a popup window, it used to appear
populated with the current folder's path. We had some logic to do this, but since now
the location entry appears in the main dialog, we can do away with that old code.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way we can re-create the contents of that box easily without disrupting
the rest of the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This will be the central function to switch operation modes: stop searches or the recent-files
process; switch widgets, etc.
We factor out the common code from recent_switch_to_browse_mode() and search_switch_to_browse_mode(),
and remove those functions. All the code that switched modes by hand now calls
the central operation_mode_set().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
That code indeed lives in operation_mode_stop(), so use it instead of
having inlined duplicates.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We'll now prefix functions to change the impl->operation_mode with 'operation_mode',
for clarity.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Various paths in SAVE or CREATE_FOLDER return from ::should_respond() but
leave an asynchronous process running. This process checks some things
in the user's selection, for example, 'does the file exist, and if so
do we need to bring up an overwrite-confirmation dialog?'. When these
async processes complete *and* it is indeed time for the dialog to
be terminated (via the response-requested signal), we also need to
save the selection to the recently-used list - as ::should_respond() does
by itself in the cases when it can request a response immediately.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
To make life easier for users, when apps don't properly update the recently-used list
after choosing a file, we now do that directly from the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
GtkThemingEngine contains a rather fantastic hack that modifies-in-place
the structure of a GParamSpec. Recent changes to GLib have caused this
hack to explode in a very bad way.
Modify the hack to check the GLib version and do the correct thing on
either side of the change.
Various paths in SAVE or CREATE_FOLDER return from ::should_respond() but
leave an asynchronous process running. This process checks some things
in the user's selection, for example, 'does the file exist, and if so
do we need to bring up an overwrite-confirmation dialog?'. When these
async processes complete *and* it is indeed time for the dialog to
be terminated (via the response-requested signal), we also need to
save the selection to the recently-used list - as ::should_respond() does
by itself in the cases when it can request a response immediately.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
To make life easier for users, when apps don't properly update the recently-used list
after choosing a file, we now do that directly from the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Basically, don't ever set the current folder, and only use
gtk_file_chooser_set_filename() for 'File/Save As'. This is so
that the file chooser will be able to present its recently-used
lists as appropriate, giving the user good suggestions by default.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
None of the cases where _gtk_file_chooser_entry_set_base_folder() appear to require
the entry highlighting the file's basename. Doing the highlighting actually makes
things look weird in Save/Recent mode if you
1. type a filename
2. click on a recent-folder,
as right after (2) your filename would get its basename highlighted for
no apparent reason.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The create-folder machinery doesn't handle that case yet; we may enable it later
once we figure out the implications for the GUI.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to be that every part of the file chooser's code would show/hide the widgets
near the pathbar as needed. Now we have two central functions:
path_bar_update()
path_bar_set_mode()
These take care of all the widget shuffling; setting the visibility of the
pathbar, info bar, and Create Folder button as appropriate; setting the contents
of the info bar, etc. - based on the current operation_mode and action.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We will centralize the place where all the pathbar-related widgets are created:
the location button, the pathbar itself, the Create Folder button, and in
subsequent commits, the info bar as well. We will deal with the pathbar/infobar
as a unit, instead of swapping them in and out in an ad-hoc fashion.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since the GtkFileChooserEntry already gets the recent-folder set upon it when a recent-folder
is selected, it already can give us the correct fully-formed path.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us do proper completion in GtkFileChooserEntry even when no base folder
has been set. Completion for relative paths won't work, as usual, as expected.
This time I realized that I needed to set autocrlf=false on my Windows side
... ugh...
This is one of those files that must have CRLF line endings to work
correctly :|
They weren't being selected in the shortcuts bar when those modes were
activated programmatically, instead of through the user selecting
them from the user interface.
In RELOAD_EMPTY mode, when no folder has been selected by the calling app, we now
start showing the recently-used list. The rationale is as follows:
- In Open mode, the user is likely to pick a file he has used recently.
- In Save mode, the user is likely to want a destination folder which
he has used recently.
For the Save case, where we want to present the user with recent folders instead
of recent files, we will make the recent-list do so in subsequent commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Introduces a 'last-folder-uri' GSettings key, where we remember the last-opened
folder from the previous instance of the file chooser.
The idea is that this works globally, across all applications, so it will be
easy to do things like
1. Save an attachment from a mail (or some other file)
2. Open another program
3. Do File/Open and automatically get sent to the folder where (1) happened.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=644426
Now we reparent the browse_path_bar_hbox to that spot in Save mode,
or to be above the file lists in Open mode. The pathbar makes for a very
clear indication of the location to save in.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
And with this we get rid of the craziness of having a separate filter model
for the combobox's model.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This effectively makes the file chooser always be in 'expanded' mode.
Later, we'll move the pathbar to the 'Save in folder:' line.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This extracts the parent folders from the items in the recently-used
list. We'll use it in the file chooser to present a list of
recently-used folders.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
-Fix the VS2010 property sheet as the DefDir "macro" needs to be updated
as well when the intermediate directories were seperated by project.
-Reinstate build/win32/vs10/gtk+.sln with the correct DOS/Windows EOL so
that file can be correctly recognized by Windows, without the
"Unrecognized Visual Studio Version" problem.
-Update solutions and projects where gtk-demo becomes gtk3-demo, to be
consistent across the board.
As Cairo and Cairo-GObject are often built as two seperate DLLs/modules,
set the property sheets to link to both libraries, instead of using the
previous approach where a monolithic Cairo DLL which contains GObject
support is used.
-Remove unneeded tags from projects
-Seperate intermediate directories for projects to avoid rebuilding/
linking on every rebuild and MSBuild errors (et al.) for not being
able to write into build log files as they are in use.
size_allocate() allocates the available space for the margin box,
get_allocation() returns the actual space of the content box and those
can be different. And then animations never stop.
If that makes you go "huh?", you might want to read
http://www.w3.org/TR/CSS21/box.html
and the docs for gtk_widget_compute_align().
This extends the current hacks in gailmenuitem to not only
recognize menuitems with labels in them, but also menuitems
which contain a GtkCellView, since those are used by GtkComboBox
nowadays.
Some of the AtkText apis are not fully supported.
https://bugzilla.gnome.org/show_bug.cgi?id=650302
This was lost when GailItem was nuked. Not having it is leading
to problems, even though randomly poking strings out of your children
seems to be a less than perfect approach to naming...
If the user pressed Enter to confirm the file chooser while the filename entry
was empty, then gtk_file_chooser_default_should_respond() would go back and forth
between the cases for handling the filename entry and the file list.
Don't rely on priv->resize_grip_visible as the code comment in the
variable declaration indicates.
This fixes warnings with GtkPlug, which can cause resize_grip_visible to
be TRUE but grid_window to be NULL - running tests/teststatusicon
reproduces this.
This broke with 0cf31b35eb
Sorry, accidently left ATK-2.0 stuff in this, should have been
ATK-1.0. doh.
Only use ATK-2.x in the coming GTK+-3.2
Also mend for GDK-Pixbuf 2.0 include path in property file.
-Added distribution for the VS 2010 project files
-Added rules in the GDK/GTK+ Makefile.am to fill in the template
project/filter files during "make dist" to ensure the source file
listing is up-to-date to simplify maintenance.
This was checked with "make dist" on Ubuntu.
Any comments on the use of the VS 2010 Projects are welcome.
These are the VS2010 project files to compile GDK and GTK+
with the Win32 backend, with a README.txt file to briefly
explain the steps to build this.
The main GDK and GTK+ project/filter files are templates
that are expanded during "make dist" so that the source
file listings in them will be up-to-date as far as
possible, simplifying maintenance.
Any comments and suggestions are welcome.
Mnemonics for characters that go beyond the baseline (q, y, g) were not
being shown, because they are drawn outside of the label's allocated
size.
This patch just disables the clip-to-size for labels, so that the label
can draw outsize of its allocation. In most cases, that works around
this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=648570
Copy over the implementation of _gtk_menu_shell_activate
so that C4013 warning/error (aka gcc's "implicit
declaration of ...") can be avoided when compiling
with MSVC.
This is in response of the changes for bug 554057 in commit
f5eee56b56.
Make the build instructions and information more
up-to-date and clearer to people
Please let me know if I have missed any details that
are needed. Thank you!
Otherwise, we end up doing maximal work with minimal effect, and
bring the X server to 100% CPU. Note that this makes spinner widgets
look really unclear, but they really have to be changed to adapt
to enable-animations == FALSE at the widget level.
The button is what draws the background/frame outline of the combobox,
and padding is defined as the spacing *inside* the widget between the
border and the content.
https://bugzilla.gnome.org/show_bug.cgi?id=646882
When the combobox is in menu mode, the right padding of the togglebutton
inside, should be allocated to its rightmost children, which is the
arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=646882
When called on a hidden window, gtk_window_present_with_time() would
just fall back to gtk_widget_show(), completely ignoring the passed-in
timestamp. This ended up working anyway if the timestamp came from
in-process, since gdk_window_x11_show() would initialize its user_time
from the time of the most recent event. But if the timestamp came from
another process, this would result in the window being shown with an
out-of-date timestamp.
Fix this by remembering the timestamp from
gtk_window_present_with_time(), and then setting the GdkWindow's
user_time from that when it the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=647275
The XI2 device manager was mistakenly setting the window user_time on
both ButtonPress and ButtonRelease, which meant that processes that
tried to launch another process based on the time of a ButtonPress
event would end up always focus-stealing-preventing the new app.
https://bugzilla.gnome.org/show_bug.cgi?id=647275
XSendEvent doesn't currently work with XI2 events, so add code to
translate core events when they have the send_event flag.
(We still don't actually select for core pointer/keyboard events, so
we will only receive send_event events that are sent with a 0
event_mask.)
https://bugzilla.gnome.org/show_bug.cgi?id=644847
This patch optimizes window resizes by assuming that if a widget
has the same height at a width of 50 as with a width of 150, the
height for width 100 will also be the same.
The patch also further optimizes the cache allocator, now there
are 2 pointer arrays of up to a maximum of 5 requests, the arrays
will only be allocated if a request is ever made in that orientation
and the array will be sparse until each request is made (i.e. if a
label can only wrap to 3 lines, there will only be 3 out of a
possible 5 SizeRequest structures allocated to cache it).
This patch makes contextual height-for-width request caching
optional (the contextual cache is not allocated for widgets that
report GTK_SIZE_REQUEST_CONSTANT_SIZE).
The constant size request mode defines a request mode where
height-for-width geometry is unneeded, thus optimizing GTK+
by reducing the overall amount of requests that need to be
performed and cached while resizing an interface.
Instead rely on state_flags & GTK_STATE_FLAG_INSENSITIVE to tell us if a
widget is sensitive.
This has the huge benefit that the way the widget is actually rendered
corresponds to the return value of gtk_widget_is_sensitive().
As a side effect, we do not ever allow unsetting the
GTK_STATE_FLAG_INSENSITIVE for a widget the is set to not be sensitive
(via gtk_widget_set_sensitive()). This way we stop propagation of making
stuff sensitive at insensitive widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=642918
Writing onto the passed-in GtkStateData could cause changes that would
propagate to siblings, as the data was not reset again.
By copying the data structure, this is avoided and the proper values are
passed to sibling widgets.
This commit makes GTK_ALIGN_START/_END pay attention to
the text direction when used in horizontal context.
This is how similar parameters in GtkMisc and GtkAlignment work,
and is generally expected of GTK+ positioning parameters. And this
is new GTK+ 3 api, so it is basically still unused at this point.
If explicit right/left turn out to be needed at some point, we
can expand the enumeration with new values.
Use the _NET_SYSTEM_TRAY_ICON_SIZE property set by the tray mananger as
a hint that we should use a specific icon size. This allows the tray to
instruct us that it expects 16x16 icons, for example.
Bug #645232
Async callbacks are delivered in idles, so we need to make sure
we get the gdk lock before calling any gdk/gtk stuff. This was
missing in a few places.
(cherry picked from commit e274dbbdce)
This ensures that widgets that aren't ported and rely on the style-set
signal being emitted work as well as before. They should not rely on
style-set being emitted however.
Note that this function is a no-op if the initial style has been set
already and is very cheap if it has not been set yet. It only becomes
relevant if the resulting style actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=639584
The intention of this patch is to make the code clearer, shorter and
most of all to avoid recreating the widget path and setting it path
twice on the style context when the style context was recreated.
Now that we have wesome macros in glib 2.0, we can use them. Woohoo, GTK
2.0 will be so awesome in the future.
(Did anybody touch dnd code this millenium?)
gtk_settings_get_default() was used to monitor the
"gtk-application-prefers-dark-theme" setting, rather
than the GtkSettings object associated with the window's
screen.
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
You can select something, but moving the focus somewhere else, or bringing up
the context menu makes the selection go away. This makes it impossible to
copy-paste the text.
The reason for this regression is that gtk_label_state_changed was sloppy and
assumed that it would only ever be called when a labels goes insensitive, which
is no longer the case.
The patch fixes things by explicitly checking if the widget is insensitive, and
only resetting the selection in that case, which is the same behaviour we have
for e.g. GtkEntry.
It turns out the bug is more complicated than I originally understood.
Not replacing the font description fields while merging here makes it
impossible for application's CSS to override fonts.
This reverts commit 89c1d93b68.
https://bugzilla.gnome.org/show_bug.cgi?id=645458
Use the background color instead.
I think the optimal solution would be delegating the shadow rendering to
the theme completely, and removing this in GtkThemingEngine, but for
now, this simple fix makes the dark variant more usable.
https://bugzilla.gnome.org/show_bug.cgi?id=645405
We were ignoring the focus ring padding, and we were incorrectly setting
handle_x to padding.left, while the draw handler already takes padding
into account while redrawing.
https://bugzilla.gnome.org/show_bug.cgi?id=645134
When tabs are not shown, and the notebook is used as a container,
we should not set the notebook style, otherwise the theme has no
way to know whether tabs are shown or not, and which colour to draw
the background.
https://bugzilla.gnome.org/show_bug.cgi?id=640692
Commit 4bb3d64414 introduced a limitation
to GtkRange style properties; when stepper-spacing is > 0,
trough-under-steppers is automatically set to FALSE; this means that
setting a spacing between the steppers (e.g. the scrollbar buttons) and
the trough (i.e. the area over which the slider is free to move) would
make the buttons always get the full allocation on the !orientation
direction.
The rationale is without this limitation, you would get an area which
seems clickable, but it's actually not.
While this is true, and undesirable, for big stepper spacings, themes
that use trough-under-steppers (which is TRUE by default anyway),
might want to set smaller spacings to avoid drawing a double line between
the button and the slider borders.
To add confusion, the documentation got it flipped, i.e. it stated
setting a positive stepper-spacing would set trough-under-steppers to
TRUE (which would also make the behavior expected by commit
4bb3d64414 impossible).
I don't think hardcoding either of the two limitations is a good thing.
We should let themes handle this instead, and remove this limitation. If
you want the old behavior, you can manually set trough-under-steppers to
FALSE if you set a positive stepper-spacing in your theme.
https://bugzilla.gnome.org/show_bug.cgi?id=644777
This incorrect assignment would cause asynchronous aborts from the X server
(they would occur if for instance, an offscreen GtkTreeView calls
gtk_widget_error_bell()).
This documentation was in direct conflict with the documentation
of gtk_tree_model_row_deleted() docs, the function docs are TRUE,
the signal docs were FALSE, fixed.
GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird
things in gtk2. We should not have to carry this forwards in gtk 3.x.
We do however keep a g_warning() call reminding people of this fact to
ease debugging when they try to port their applications.
https://bugzilla.gnome.org/show_bug.cgi?id=644119
parse_value() could fill in a GError, but yet (incorrectly) return G_TOKEN_NONE,
having the GError leaked as a result.
https://bugzilla.gnome.org/show_bug.cgi?id=642604 , Reported by Felix Riemann.
This code is a relic from GTK2 days and should not be necessary anymore,
as code now makes sure to only copy those parts of the window that are
not overlapped by parent windows.
By deleting it we fix potential issues with composited and translucent
windows copying the wrong data.
https://bugzilla.gnome.org/show_bug.cgi?id=643416
Use lower level methods that just require changing the state in the
GtkStyleContext instead. Fixes a problem where the insensitive state
was being set to the entry becasuse a parent was insensitive, spotted
by Alex Larsson.
The render order for tabs is now
- left to right until the active tab
- right to left until the active tab
- active tab
This allows themes that use non-straight lines for the tab curvature to
draw them not worrying about flipping one side after the active tab.
Let the tab overlap eat the padding, otherwise having tab-overlap >
tab-curvature without cutting the label is impossible.
This way we give the label widget all the allocation possible before
giving up and cutting it if the values for tab-overlap are too extreme
for the given padding.
Previously, the inactive state caused the spinner's solid line to be
drawn to the right. Now it's drawn to the top instead, which makes the
inactive state look more natural.
Previously, for i == 0, we were drawing the translucent line first.
However, people reading the code would always assume the solid line is
indicated by the current step. So make the code do that.
Note that the spinner now rotates in the wrong direction. This will be
fixed in a future commit.
* gtk/gtkmain.c: (gtk_init): Mention that argc and argv can be 0,
using the new text from the g_applicatoin_run() documentation.
There was already introspection annotation about that.
(gtk_init_check, gtk_init_with_args): Use the same text here.
See bug #643649 comment 2.
This is in preparation for making scale marks styling better.
As a side-effect, TOP and LEFT position are treated the same now,
as well as BOTTOM and RIGHT.
Based on a patch by Bastien Nocera,
https://bugzilla.gnome.org/show_bug.cgi?id=643685
GtkWidget now parses custom attributes like
<style>
<class name="dark-label"/>
<class name="big-heading"/>
</style>
to add style classes to widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=643347
Set the Mac key theme when creating a Quartz settings object instead of
having it the default when quartz is enabled.
This keeps compatibility with the GTK2 behavior that the Mac key theme
is not used for the X11 backend, which could now happen for a
multi-backend build.
Previously we were enabling some settings properties only if the X11
backend was enabled. This worked fine with GTK2 where only one backend
was enabled at a time, but now when multiple backends can be enabled,
this does not make sense.
GtkSwitch was listening for Space/Enter keyreleases itself, instead
of providing an 'activate' action signal, like e.g GtkButton. As a
side-effect, this fixes
https://bugzilla.gnome.org/show_bug.cgi?id=643321
In this patch we adress rows_reordered() and row_deleted() callbacks
(since some icon view subclasses manipulate the connected treemodel
from _init()).
We were breaking prematurely out of the loop that goes through
each file that is pending selection; not only does that loop
disable filtering and show hidden files if needed, but it also
selects the files themselves. So we need to walk the whole
list of files.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=643170
The monitor change detection code in _gdk_x11_screen_size_changed() and
process_monitors_change() goes to some length to make sure its only emitted
when there is an actual change to the data visible via the GdkScreen monitors
api.
However, commit 662e69ad added some code that always emits "monitors-changed"
in _gdk_x11_screen_size_changed when we have randr13 and get a ConfigureNotify
on the root window (even though we may already have emitted it in the
RRScreenChangesNotify event!).
As far as I can tell this is due to a comment in the bug referenced by the
commit (https://bugzilla.gnome.org/show_bug.cgi?id=601712#c4) where it says:
This version of the patch changes GdkDisplay to emit "monitors-changed" when
the primary monitor changes (see the change in _gdk_x11_screen_size_changed).
And, if you remove this part of the change the signal is not emitted when just
the primary is changed. However, this is not really the right approach. We
should just also check for if the primary changes in process_monitors_change()
to avoid spurious signal emissions.
https://bugzilla.gnome.org/show_bug.cgi?id=643216
Adding these cases here to cater to icon view subclasses that want to
access icon view APIs from the instance structure initializer instead
of properly waiting for the super class to initialize and adding renderers
from the ->constructor() vfunc.
The last paragraph still seems to be out of place though, as if it
was a previous attempt at an overview or part of some older text
elsewhere.
This overuses the passive too.
This avoids overflow when transforming a large value to a pango unit.
To reproduce the problem:
seq 200000 > test.txt && tets/print-editor test.txt
Then scroll to around line 140.000 to see it (depends on font size of
course).
gtk_tree_model_filter_row_deleted was emitting ::row-deleted while
the internal state of the model was still in disarray, causing
segfaults e.g. when mapping the file chooser with accessibility
turned on. This is just a bandaid fix, and doesn't try address
any of the deeper problems of the filter model code.
I did take the time to reduce rampant variable shadowing in that
function, though.
Now that a single shared object can contain multiple backends we also
need to provide a simple way for third party code to verify that the
copy of GDK they are linking to supports their backend.
The simplest way to verify is an m4 macro, GTK_CHECK_BACKEND(), shipped
with the gtk+ m4 macros.
The usage is pretty basic:
GTK_CHECK_BACKEND([x11], [gtk_has_x11=yes], [gtk_has_x11=no])
AM_CONDITIONAL(BUILD_X11_CODE, test "x$gtk_has_x11" = "xno")
https://bugzilla.gnome.org/show_bug.cgi?id=642479
If a level 1 key maps to a key value passed to
gdk_test_simulate_key(), raise the GDK_SHIFT_MASK flag so the reqested
key value is generated. Also add a regression test for this fix.
On Windows and OS X we want to prefer the native backends over the X11
backend.
On Linux, nothing changes as nobody is going to enable those backends
(and if they do, they'll know what they get).
Previously we weren't installing the device headers when compiling
without XINPUT support. But we would include them from gdkx.h, so
essentially the build was broken.
With this patch the types will exist but not do anything.
which happened when the source widget was hidden or destroyed while a
drag was going on, like when dragging from a popup that got a grab
broken as result of the dnd operation.
Apparently I previously had one of the source files wrong here...
Update this to reflect the correct file.
My fault for not seeing this earlier-sorry. DOH.
At the same time, change the library sonames for -3.0 to just -3.
This is necessary since the 2.99 releases installed libraries like
libgtk-3.0.so.0.9903.0, and we want to prevent the library version
number from jumping back. So 3.0 will have libgtk-3.so.0.0.0.
This was an oversight in the recent accel label improvement.
When we get an untranslated string back from gettext(), it is
not ok to replace '_' by ' ' in-place. Instead, do it while
appending to the GString.
https://bugzilla.gnome.org/show_bug.cgi?id=641912
This operation is potentially expensive, so the code has been
refurbished so avoid the cases it was needed for. Antialiased
cairo_clip() has been also reduced to transitions with surface
patterns involved.
Gdk-3.0 is already included above via --include-uninstalled, so
don't also specify it in INCLUDES. Doing so breaks if it isn't
installed already, since we try to find the gdk-3.0.pc.
Gdk-3.0 is already included above via --include-uninstalled, so
don't also specify it in INCLUDES. Doing so breaks if it isn't
installed already, since we try to find the gdk-3.0.pc.
It was unclear in the docs what happened if
gtk_style_context_add_provider() and
gtk_style_context_add_provider_for_screen()
were used with the same priority.
Sensitivity changes were not properly propagated down the
hierarchy. There were two issues here:
a) correctly identifying when a state change request affects
sensitivity
b) not filtering out sensitivity in gtk_widget_propagate_state(),
since gtk_widget_set_sensitivity() uses that to do its work
https://bugzilla.gnome.org/show_bug.cgi?id=641431
Optimized GtkSizeGroup code that is invoked for every queued resize
and every request that is not previously cached by trading qdata on
widgets for 3 extra bitfields on the GtkWidgetPrivate structure.
AC_C_CONST: current C compilers support const
AC_TYPE_SYGNAL: obsolete when assuming C89 or better
AC_HEADER_STDC: current systems have conforming header files
- replace GdkNativeWindow with HWND, remove type casts
- no more GdkDisplayClass::get_drag_protocol but GdkWindowImpl::get_drag_protocol
- remove *_client_message*()
so pull the SELECTED state flag out of the !sensitive branch. Also,
don't make FOCUSED depend on SELECTED here, it's up to the widget to
decide whether or not that is possible.
It is used to get the default providers, without them
the style context can't do much. A check for NULL screen
is done before any sensitive call to
gtk_style_context_set_screen(), in the hope that any widget
will open the display before doing anything related to
styling. Fixes bug #641429, reported by Bastien Nocera.
Before this patch, unsetting the filter manually before disposing
the recent chooser menu (or unsetting the filter twice), would cause
warnings (or invalid memory accesses).
Just a noop that is better than crashing in the case this is called
(it can be called for a toplevel GtkWindow that is parented into
another widget by setting gtk_widget_set_parent_window to an offscreen
window).
Having default implementations on abstract classes that do nothing
or print errors make life easier for language bindings implementors,
inside GTK+ this makes little or no difference.
Having default implementations on abstract classes that do nothing
or print errors make life easier for language bindings implementors,
inside GTK+ this makes little or no difference.
constructors which take an object of the same class as its first argument are
mis-detected as method call with "self" argument by the GIR scanner. Using the
new (constructor) annotation from bug 561264, mark some of them as proper
constuctors, so that you can call them with NULL as first argument from
bindings; in particular, this fixes gdk_window_new() and the
gtk_radio_button_new_with*() constructors.
b3f6f67c changed the loop from while() to for() in gtk_fixed_forall(),
but that's wrong since the callback can have side-effects on the list,
in case the current child gets removed. And that's the case when the
widget is destroyed.
Patch by Vincent Untz
https://bugzilla.gnome.org/show_bug.cgi?id=641196
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
It turns out that the gtk_grab_remove() can trigger a do_prelight()
call, which may end up changing prelight_node, and then the state
gets messed up. Moving the grab removal until after we're done with
button_pressed_node and prlight_node makes expanders work reliably.
One thing that is still not right is that the expander doesn't get
prelight again after the animation is done, if you manage to release
without any additional motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=641039
... and all APIs making use of it.
That code like it hasn't been touched in years, Google codesearch
didn't find any users and most importantly it's a horrendous API, so
let's just make it die instead of having to port it over to
non-GdkNativeWindow usage, which would be required for multi-backend
GDK.
http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00049.html
I've decided that it is isn't feasible to make cell areas runtime-settable
in the time we have left before 3.0, therefore, I'm going with the
approach to allow init() functions to instantiate the default cell area
and issue a warning if a construct property is ignored.
This is not ideal, but it keeps existing icon view and combo box
subclasses working.
https://bugzilla.gnome.org/show_bug.cgi?id=639139
The forall() loop was buggy as it was skipping items in the list when
the current item gets removed from the groups array as a result of
calling the callback (causing memory leaks).
Use GdkWindow instead. This requires calling
gdk_x11_window_foreign_new_for_display(), so might cause a slight
performance penalty, but is required to be portable.
Make gtk_binding_entry_add_signal_from_string() return the expected
token in case of parsing error, so that we can return a GError
instead of spewing. Also, add a separate scope for binding-set,
since allowing {} in identifiers in SCOPE_VALUE breaks the fact
that the ; after the last assignment in a rule is optional.
This is done in the same place than it was done before the switch
to GtkStyleContext, the GtkBindingEntry has been slightly simplified
since it's now the GtkStyleContext which hands us the list
of binding sets applying to a widget, so no need to use the older
matching mechanisms.
This property takes a list of binding set names to have these
stored as a GPtrArray containing GtkBindingSets. this property
is handled so merging GtkStyleProperties will merge both
GtkBindingSet lists.
these custom rules can be used to define key themes
as in the RC files, a series of bind/unbind rules
may be added then:
@binding foo-bar {
bind "<alt>1" { "move-cursor" (visual-positions, 1, 0) };
unbind "<ctl>d"
}
When loading a theme, make sure we take into account the variant
so we don't use the plain version when the theme changes.
Also make sure to fallback to the plain theme when loading a variant
fails.
https://bugzilla.gnome.org/show_bug.cgi?id=640983
This management is better done per-widget rather than per-screen,
as windows being destroyed won't trigger a leave notify for the
devices on top of it, and this information is too transitive
to keep weak refs and such.
This fixes the critical warning seen in gtk/tests/testing.
Move the private get_cursor_color method belongs to StyleContext. Change
the api so that retrieving both primary and secondary color is possible.
I left the method private for now, though it should probably be public
as all the other getters.
People agreed that it doesn't make sense to make an xembed
implementation like plug/socket does not make sense on anything but X11.
And as GdkNativeWindow is going away for multibackend portability
reasons, we'd either need API fixes in the plug-socket codee or
constrain the widgets to a single backend. We chose the latter.
Instead of checking if klass->get_request_mode is != NULL from
the gtk_widget_get_request_mode() api, this allows classes to
trust that there is a default implementation and chain up (specifically
added this for gtkmm wrapper objects).
Expander animation has been replaced by implicit animations
from the style context.
Column headers are also properly themed, GtkContainer::get_path_for_child()
is implemented and the treeview resets column buttons style on columns
being reordered.
The default CSS has changed to theme treeviews sensibly.
I think it's confusing for a lot the developers out there who
may not even be aware of GTK+ 3 coming, if suddenly GTK+ 3 becomes
the "stable" version of "gtk" on library.gnome.org. It may
not even be feasible for them to port to GTK+3 if it's not
shipped in the operating systems they're targeting (for example,
RHEL 6).
Since practically speaking, we expect people to consume GTK+ 2 for
several years at least, redirect these people to the right pages.
(I didn't attempt to explain the differences between the libraries
here, but hopefully the major version difference is enough of a hint)
As a side effect, this makes the generated HTML look better; previously
it looked rather crappy, since the "for GTK &version;" was totally
offset and in a different group from the documentation title.
This lets themes override settings values again. We are using
the same priority that was used from the rc file parser, so things
are largely unchanged, relative to other settings sources.
Move key file parsing to gtk_settings_load_from_key_file(), in
preparation for loading per-theme files. Load key files from both
/etc and ~/.config, with the latter overriding the former. Support
parsing enum values.
Also added documentation section for this. Since the GtkRecentFilter
documentation was still living in sgml, as a side-effect I migrated these
docs to the gtkrecentfilter.[ch] sources.
GtkStateType was generally used as an index in GtkStyle color arrays, so
bigger values will cause invalid memory accesses in widgets that are still
doing that. this was seen in focused GtkIconViews for example
Only master devices must modify the associated device to separate
a pointer/keyboard pair, slave devices must only call
_gdk_device_remove_slave().
Fixes bug 639767 - password not accepted in gnome-screensaver dialog,
reported by Frederic Crozat. On VT-switch, the X server removes its
grab on HW devices, the effect on clients is that slave devices
disappear, and these were mistakenly mangling the master device
hierarchy. so gdk_device_get_associated_device() on the client
pointer wouldn't return the paired keyboard anymore.
The final effect is that gtkplug-x11 wasn't setting a keyboard to
its generated events.
slave devices don't have coordinates themselves, as they depend
on a master, this only changes if they have a grab in effect,
so only keep toplevel tracking enabled in such situation. Fixes
Bug #640313 - BadDevice X error when ungrabbing a SLAVE device,
noticed by Jesse van den Kieboom.
This function allocates the button mask, so free it after
use, or right before the next XIQueryPointer() call, as done
in gdk_x11_device_xi2_window_at_position().
mods_state->effective is not being set in XIQueryPointer() currently, so
use base|latched|locked instead, effective is nothing else than a shorthand
for these ORs, and these 3 values are set correctly anytime.
together with commit 8903615a34, this finally fixes bug #640282.
Insensitivity is handled separatedly in _gtk_widget_update_state_flags(),
but the insensitive flag is mistakenly unset afterwards if clear is TRUE
in gtk_widget_set_state_flags().
-Updated README.txt file in build/win32/vs9.
-Fix the gdk.vcprojin and gtk+.vsprops regarding include paths
and copying of headers (missed header etc.)
When set to PANGO_ALIGN_CENTER, text was rendered off-center
by the amount of 'free space' that the PangoLayout left (ie
the x returned by pango_layout_get_pixel_extents).
The logic was to try to switch to that nonexistent folder and thus get
an error message presented. However, no such message actually appears,
as the file chooser tries to switch to the closest parent folder that
actually exists, without bringing up an error message --- this is done
to cope with the case of the file chooser being started with a folder
that doesn't exist anymore.
Now, we just bring up an error message directly when we detect that
the user types a subfolder name that doesn't exist.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We used to explicitly map and unmap the child GtkFileChooserWidget when
mapping and unmapping the dialog, respectively. Now that GtkWidget actually
unmaps child widgets (instead of avoiding that), we can assume that the
child GtkFileChooserWidget will be unmapped when we wanted it to be.
This fixes a warning that happened with the new GtkWidget invariant checker,
as we were mapping our child widget before calling our parent class' ::map() handler.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Buttons may also be activated at any time from gtk_widget_activate()
or related functions. In that case, just do the 'show the button
as pushed for a short amount of time' trick, but don't actually
try to grab the keyboard device.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There is only one widget supposed to have the focused flag at a given time,
so avoid propagating the state down the hierarchy, the focused flag is now
also set in _gtk_widget_set_has_focus().
The transfer annotation was (transfer full) but the caller actually
doesn't own a reference of the object. This made the pygobject test suite
crash because pygobject was trying to unref the returned GtkButton
instance.
https://bugzilla.gnome.org/show_bug.cgi?id=639949
The state attribute is available in GdkEventMotion, GdkEventButton,
GdkEventScroll, GdkEventKey and GdkEventCrossing. This type annotation
fixes the wrapping of this attribute in the GI PyGObject bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=639929
When copying allocated events, also copy the source device.
When synthesizing double or triple clicks, copy the original
button press event including device information.
https://bugzilla.gnome.org/show_bug.cgi?id=639822
In GTK 3.0 it's no longer possible to e.g. pop up something
at a text view's cursor (this wasn't exactly possible before
either without including gtktextlayout, but this is a quite
special need anyway).
Commit 80e1340e introduced using a GDK method in examples/drawing.c, so
actually link that to GDK. Fixes build failure with --as-needed linker option
and gcc 4.5.
Fixes bug #Bug 639754, reported by Kjell Ahlstedt. gtkmm doesn't
use plain CamelCase for its widget type names, so in order to
distinguish widget type names from regions in the CSS parser,
the following checks are now done:
* if it contains an uppercase letter -> widget class (that should
also work for gtkmm)
* if it's a string compound by lowercase letters and '-' -> it's
a region, checks have been added in gtk_style_context_add_region()
and gtk_widget_path_iter_add_region() to ensure this.
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
When converting to gtk3, replace GtkComboBoxEntry with GtkComboxBox
has-entry=True, and remove the has-separator property from GtkDialogs.
Bug #639327.
The assertions here were not accounting for the possiblility of
zero width visible renderers that are aligned completely to the
right (i.e. renderers with no content set for a said row).
-Update the project files to simplify them a bit after the seperation of
GDK-Pixbuf (move GDK-Pixbuf includes into the property sheet, move the
linking of Cairo/Pango/PangoCairo into the property sheet)--this is for
all DLL/EXE Projects (GDK/GTK/gtk-demo)
-Update the GDK-Win32 project as the source files have changed
significantly (especially as GDK3 was not compilable on Windows for a
while--thanks to Hans Breuer for the help in the process-Bug 639127)
-Made up for missed headers in the "install" stage and removed the removed
headers in the property sheet
-Updated GTK+ .def file generation as an extra macro is needed for that
-Updated gdk/Makefile.am for the generation of gdk.vcproj from gdk.vcprojin
-Update the project files to simplify them a bit after the seperation of
GDK-Pixbuf (move GDK-Pixbuf includes into the property sheet, move the
linking of Cairo/Pango/PangoCairo into the property sheet)--this is for
all DLL/EXE Projects (GDK/GTK/gtk-demo)
-Update the GDK-Win32 project as the source files have changed
significantly (especially as GDK3 was not compilable on Windows for a
while--thanks to Hans Breuer for the help in the process-Bug 639127)
-Made up for missed headers in the "install" stage and removed the removed
headers in the property sheet
-Updated GTK+ .def file generation as an extra macro is needed for that
-Updated gdk/Makefile.am for the generation of gdk.vcproj from gdk.vcprojin
GTK_STYLE_PROPERTY_BORDER_WIDTH is of style GtkBorder, not gint.
Also make it clearer what the definition and ordering of these 3
properties is. Reorder them in the header to be more logical.
This function is a more convenient variant than
gtk_widget_set_device_events(), as it will
1) perform changes down a widget hierarchy, to
all windows.
1) use the same event mask than gdk_window_get_events()
This function will be needed in widgets like GtkTreeView,
since gdk_window_scroll() doesn't trigger the usual
mechanisms to update the invalidation area, this function
is needed together with it.
This function takes a region ID and cancels all animations
on or beneath that region (as in push/pop_animatable_region).
First user of this is GtkWidget itself, so unmapped widgets
have looping animations cancelled. Fixes bug #638119, reported
by Jesse van den Kieboom.
prepare_run must have been called before draw_shape, so we can avoid
fiddling the the (deprecated) style and state and just use the color
alredy set on the renderer.
https://bugzilla.gnome.org/show_bug.cgi?id=639079
This makes XEmbed work properly again. Only event->key.group
and is_modifier are left blank at the moment. Exposing the
necessary XKB bits should be considered, but it's not urgent
for the current usecases.
This function is useful to figure out whether the tree view is "blank"
at a given location. For such locations you might want to popup a
custom popup menu, clear the current selection or start rubber banding.
In the future, we are planning on updating GtkTreeView's user
interactions to take advantage of this new function.
Part of bug 350618.
The fact that GtkCellLayout was checking "if (gtk_cell_layout_get_area (layout))"
and executing code contitionally from the apis instead of simply falling
back to the default implementation for these things was causing problems
in language bindings such as gtkmm... Regardless, the implementation
is cleaner this way too.
- Made notebook tabs smaller
- No need to hide/show toplevels after removing from a parent,
if it's visible it will be automatically shown after removing
outside of it's previous parent.
This involves checking the toplevelness of new toplevels before connecting
but not the *old* ones for disconnecting signals. Also take care of handling
a row_reference that becomes invalid over the course of reparenting the
filechooser into another parent.
Now GtkWindow takes some measures when setting toplevelness:
- When a window becomes toplevel after being embedded it saves
the visibility state and reshow's itself so that the window
re-realizes and presents itself again automatically
- When emitting hierarchy-changed, synthetically mark the toplevel
as not anchored, this allows the hierarchy changed propagation to
recurse properly.
GtkWidget also takes care to unset the parent window *after* unparenting
the widget and after emitting the heirarhcy changed that leaves a NULL
toplevel.
That means there are now 2 cycles of "hierarchy-changed" when removing
an embedded toplevel from a parent, first one that makes the new toplevel
a NULL one (since the toplevel flag is not yet restored), the second cycle
makes the removed window toplevel again when setting the parent window
to NULL.
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
This patch makes gtk_widget_set_parent_window() undo the toplevelness
of a GtkWindow, GtkWindow then realizes itself as a normal child widget
and behaves like a normal GtkBin by checking gtk_widget_is_toplevel() in
several places (show/hide/map/unmap/draw/size_allocate/check_resize/configure_event).
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).
This is a subclass of GEmblemedIcon that can show a number or
short string as an emblem, overlayed on top of another emblem.
Written by Cosimo Cecchi
https://bugzilla.gnome.org/show_bug.cgi?id=637169
For ellipsize cells it's important to clip the result of get_size()
so that the returned required rectangle is indeed less than or equal
to the input rectangle... this is done so that GtkCellArea can accurately
paint focus on cells by calling gtk_cell_renderer_get_aligned_area().
Patch also adds assertions to gtk_cell_renderer_get_aligned_area() to
ensure this keeps working correctly.
- 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>
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 ##### -->
is a numeric index into a string table on the X server. They are used
to transfer strings efficiently between clients without
having to transfer the entire string.) A property
has an associated type, which is also identified
using an atom.
</para>
<para>
A property has an associated <firstterm>format</firstterm>,
an integer describing how many bits are in each unit
of data inside the property. It must be 8, 16, or 32.
When data is transferred between the server and client,
if they are of different endianesses it will be byteswapped
as necessary according to the format of the property.
Note that on the client side, properties of format 32
will be stored with one unit per <emphasis>long</emphasis>,
even if a long integer has more than 32 bits on the platform.
(This decision was apparently made for Xlib to maintain
compatibility with programs that assumed longs were 32
bits, at the expense of programs that knew better.)
</para>
<para>
The functions in this section are used to add, remove
and change properties on windows, to convert atoms
to and from strings and to manipulate some types of
data commonly stored in X window properties.
</para>
<!-- ##### SECTION See_Also ##### -->
<para>
</para>
<!-- ##### SECTION Stability_Level ##### -->
<!-- ##### SECTION Image ##### -->
<!-- ##### STRUCT GdkAtom ##### -->
<para>
An opaque type representing a string as an index into a table
of strings on the X server.
</para>
<!-- ##### MACRO GDK_ATOM_TO_POINTER ##### -->
<para>
Converts a #GdkAtom into a pointer type.
</para>
@atom: a #GdkAtom.
<!-- ##### MACRO GDK_POINTER_TO_ATOM ##### -->
<para>
Extracts a #GdkAtom from a pointer. The #GdkAtom must have been
stored in the pointer with GDK_ATOM_TO_POINTER().
</para>
@ptr: a pointer containing a #GdkAtom.
<!-- ##### MACRO GDK_NONE ##### -->
<para>
A null value for #GdkAtom, used in a similar way as <literal>None</literal>
in the Xlib API.
</para>
<!-- ##### FUNCTION gdk_text_property_to_text_list ##### -->
<para>
Converts a text string from the encoding as it is stored in
a property into an array of strings in the encoding of
the current local. (The elements of the array represent
the nul-separated elements of the original text string.)
</para>
@encoding: an atom representing the encoding. The most common
values for this are <literal>STRING</literal>,
or <literal>COMPOUND_TEXT</literal>. This is
value used as the type for the property.
@format: the format of the property.
@text: the text data.
@length: the length of the property, in items.
@list: location to store a terminated array of strings
in the encoding of the current locale. This
array should be freed using gdk_free_text_list().
@Returns: the number of strings stored in @list, or 0,
if the conversion failed.
<!-- ##### FUNCTION gdk_text_property_to_text_list_for_display ##### -->
<para>
</para>
@display:
@encoding:
@format:
@text:
@length:
@list:
@Returns:
<!-- ##### FUNCTION gdk_free_text_list ##### -->
<para>
Frees the array of strings created by
gdk_text_property_to_text_list().
</para>
@list: the value stored in the @list parameter by
a call to gdk_text_property_to_text_list().
<!-- ##### FUNCTION gdk_text_property_to_utf8_list ##### -->
<para>
</para>
@encoding:
@format:
@text:
@length:
@list:
@Returns:
<!-- ##### FUNCTION gdk_text_property_to_utf8_list_for_display ##### -->
<para>
</para>
@display:
@encoding:
@format:
@text:
@length:
@list:
@Returns:
<!-- ##### FUNCTION gdk_string_to_compound_text ##### -->
<para>
Converts a string from the encoding of the current locale
into a form suitable for storing in a window property.
</para>
@str: a nul-terminated string.
@encoding: location to store the encoding atom (to be used as the type for the property).
@format: location to store the format for the property.
@ctext: location to store newly allocated data for the property.
@length: location to store the length of @ctext in items.
@Returns: 0 upon sucess, non-zero upon failure.
<!-- ##### FUNCTION gdk_string_to_compound_text_for_display ##### -->
<para>
</para>
@display:
@str:
@encoding:
@format:
@ctext:
@length:
@Returns:
<!-- ##### FUNCTION gdk_free_compound_text ##### -->
<para>
Frees the data returned from gdk_string_to_compound_text().
</para>
@ctext: The pointer stored in @ctext from a call to gdk_string_to_compound_text().
<!-- ##### FUNCTION gdk_utf8_to_string_target ##### -->
<para>
</para>
@str:
@Returns:
<!-- ##### FUNCTION gdk_utf8_to_compound_text ##### -->
<para>
</para>
@str:
@encoding:
@format:
@ctext:
@length:
@Returns:
<!-- ##### FUNCTION gdk_utf8_to_compound_text_for_display ##### -->
<para>
</para>
@display:
@str:
@encoding:
@format:
@ctext:
@length:
@Returns:
<!-- ##### FUNCTION gdk_atom_intern ##### -->
<para>
Finds or creates an atom corresponding to a given string.
</para>
@atom_name: a string.
@only_if_exists: if %TRUE, GDK is allowed to not create a new atom, but
just return %GDK_NONE if the requested atom doesn't already
exists. Currently, the flag is ignored, since checking the
existance of an atom is as expensive as creating it.
@Returns: the atom corresponding to @atom_name.
<!-- ##### FUNCTION gdk_atom_intern_static_string ##### -->
<para>
</para>
@atom_name:
@Returns:
<!-- ##### FUNCTION gdk_atom_name ##### -->
<para>
Determines the string corresponding to an atom.
</para>
@atom: a #GdkAtom.
@Returns: a newly-allocated string containing the string
corresponding to @atom. When you are done
with the return value, you should free it
using g_free().
<!-- ##### FUNCTION gdk_property_get ##### -->
<para>
Retrieves a portion of the contents of a property. If the
property does not exist, then the function returns %FALSE,
and %GDK_NONE will be stored in @actual_property_type.
</para>
<note>
<para>
The XGetWindowProperty() function that gdk_property_get()
uses has a very confusing and complicated set of semantics.
Unfortunately, gdk_property_get() makes the situation
worse instead of better (the semantics should be considered
undefined), and also prints warnings to stderr in cases where it
should return a useful error to the program. You are advised to use
XGetWindowProperty() directly until a replacement function for
gdk_property_get()
is provided.
</para>
</note>
@window: a #GdkWindow.
@property: the property to retrieve.
@type: the desired property type, or %GDK_NONE, if any type of data
is acceptable. If this does not match the actual
type, then @actual_format and @actual_length will
be filled in, a warning will be printed to stderr
and no data will be returned.
@offset: the offset into the property at which to begin
retrieving data, in 4 byte units.
@length: the length of the data to retrieve in bytes. Data is
considered to be retrieved in 4 byte chunks, so @length
will be rounded up to the next highest 4 byte boundary
(so be careful not to pass a value that might overflow
when rounded up).
@pdelete: if %TRUE, delete the property after retrieving the
data.
@actual_property_type: location to store the actual type of
the property.
@actual_format: location to store the actual return format of the
data; either 8, 16 or 32 bits.
@actual_length: location to store the length of the retrieved data, in
bytes. Data returned in the 32 bit format is stored
in a long variable, so the actual number of 32 bit
elements should be be calculated via
@actual_length/sizeof(glong) to ensure portability to
64 bit systems.
@data: location to store a pointer to the data. The retrieved
data should be freed with g_free() when you are finished
using it.
@Returns: %TRUE if data was successfully received and stored
in @data, otherwise %FALSE.
<!-- ##### FUNCTION gdk_property_change ##### -->
<para>
Changes the contents of a property on a window.
</para>
@window: a #GdkWindow.
@property: the property to change.
@type: the new type for the property. If @mode is
%GDK_PROP_MODE_PREPEND or %GDK_PROP_MODE_APPEND, then this
must match the existing type or an error will occur.
@format: the new format for the property. If @mode is
%GDK_PROP_MODE_PREPEND or %GDK_PROP_MODE_APPEND, then this
must match the existing format or an error will occur.
@mode: a value describing how the new data is to be combined
with the current data.
@data: the data
(a <literal>guchar *</literal>
<literal>gushort *</literal>, or
<literal>gulong *</literal>, depending on @format), cast to a
<literal>guchar *</literal>.
@nelements: the number of elements of size determined by the format,
contained in @data.
<!-- ##### ENUM GdkPropMode ##### -->
<para>
Describes how existing data is combined with new data when
using gdk_property_change().
</para>
@GDK_PROP_MODE_REPLACE: the new data replaces the existing data.
@GDK_PROP_MODE_PREPEND: the new data is prepended to the existing data.
@GDK_PROP_MODE_APPEND: the new data is appended to the existing data.
<!-- ##### FUNCTION gdk_property_delete ##### -->
<para>
Deletes a property from a window.
</para>
@window: a #GdkWindow.
@property: the property to delete.
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.
