We don't want to include the whitespace after an import statement.
Because people tend to add newlines after @import, we report the wrong
lines for failed imports. And that's bad.
"The child window MUST also have the _NET_SUPPORTING_WM_CHECK property set to
the ID of the child window. […] If the _NET_SUPPORTING_WM_CHECK window on the
client window is missing or not properly set, clients SHOULD assume that no
conforming Window Manager is present."
This commit implements that, which allows us to not have to do a
XGetWindowProperty() every N seconds when running under a compliant WM.
This is also a more correct fix for the bug handled in commit
daf29bffed.
https://bugzilla.gnome.org/show_bug.cgi?id=666921
There are new calls to load ui files from resources, and
you can now read pixbufs by using relative paths in a ui
file read from a resource, or by using absolute resource:/// uris.
Was getting this error:
main.c:785:13: error: ‘gtk_demos’ undeclared (first use in this function)
main.c:785:13: note: each undeclared identifier is reported only once for each function it appears in
main.c: In function ‘main’:
Problem pointed out by Stefan Sauer in bug 667598. The solution
here is different from his patch. We always draw marks in increasing
direction, and flip the marks and stop positions to match.
When finding the width for a given height, we can pass the full
height to both the menubar and the content. Instead, give the
menubar its minimum height, and give the rest to the content.
The code was not properly removing the menubar height from the
height given to the content, causing the statusbar to drop off
the bottom of the window in some examples.
This follows the approach used by the Quartz port - that of a separate
implementation matching GtkClipboard.
The simple clipboard tests in gtk3-demo function correctly but there are
almost certainly leaks and bugs.
This is useful to sketch out in GtkBuilder widgets in different states
all at once, so that we can check theming is right for them.
Add some initial UI files for primary-toolbar and inline-toolbar widgets.
gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
Instead, focus nothing and wait until we get focus before doing so. This
restores previous behaviour but still emits proper cursor-changed
events.
Fixes a bunch of bugs in the filechooser which populates the treeview
asynchronously.
https://bugzilla.gnome.org/show_bug.cgi?id=613728
It was always looking at the 'color' keyword for the parent context
instead of only doing that when used with the 'color' property.
Tested by border-color-default.ui reftest.
Add a switch. This demonstrates:
- that switches can be placed in toolbars
- that GtkSwitch is actionable
- that actions can be shared between multiple actionables
We don't expose ::quit-requested as API anymore. Instead, we expect
users to register inhibitors when needed. Without quit-requested,
there is no need for ::quit-cancelled and gtk_application_quit_response
anymore.
We still emit ::quit when the application is about to quit.
The part in gdkwindow-x11.c which uses XIEvent and friends is "protected"
by HAVE_XGENERICEVENTS, i.e., XGetEventData() has been found. (Xlib.h)
XIEvent and friends are defined in <X11/extension/XInput2.h> which is
included by gdkdisplay-x11.h if XINPUT_2 is defined.
The patch makes sure XIEvent is only used if XINPUT_2 is defined.
https://bugzilla.gnome.org/show_bug.cgi?id=667534
Replace all references to g_application_set_app_menu and
g_application_set_menubar by their gtk variants, which
actually exist. Pointed out in bug 667546
'window-unfocused' is too long and mentions "focus" which is historically
loaded with the meaning "input focus".
'backdrop' isn't generally used in GUI speak and still conveys the state the
widgets in an unfocused or background toplevel window are in.
This reverts commit c276f53796 and
implements the same feature using the compute function.
A nice side effect is that gtk_style_property_get_border() and
gtk_style_property_get("border") to the same thing now.
When using G_TYPE_NONE as the shorthand's type, the property is not
gettable/settable using regular APIs, so it essentially doesn't exist.
As it should be.
We want to make sure to fall back to the initial value of the property
if resolving fails.
This is kinda tricky, because the initial value itself might need
resolving, too.
Instead of on-demand resolvage, we now resolve during lookup. The step
is done via
_gtk_css_style_property_compute_value()
which currently calls into
_gtk_css_style_compute_value()
That function has all the old resolving machinery.
The only part missing for now is the handling of win32 code. It will be
added back later.
This would make the internal properties custom properties. And they are
not.
Also get rid of default initial values, we now specify the correct one
at all times.
We can't print shorthands, so don't try.
In particular, I want to get away from shorthands being representable
using GValue, and this function kinda requires that.
... in gtk_style_properties_lookup_property(). Those properties will
soon stop having pspecs or even being gettable and settable, so better
not tell anyone about it.
One test has all properties set to 'inherit', the other to 'initial'.
This should result in the same result, as inherit will ensure every
widget inherits the same value, and for the toplevel 'inherit' is
defined as being identical to 'initial'.
Passing the length of the widget path that is relevant is not necessary
anymore, it was only useful for inheritance. Instead, we now pass the
state flags and let the selector do the state matching for us.
See inline code comments taken from
http://dev.w3.org/csswg/css3-cascade/#cascade
This now respects the special values "inherit" and "initial" properly.
Note that those values cannot be parsed yet. This will be added in a
future commit.
We now use the GtkStleProviderPrivate interface, which hopefully is
faster and more conformant to CSS. Long term, it definitely should be
both.
I would have liked to split this up into multiple commits, but couldn't
find a way.
The GtkScaleMark values are gdouble, a simple a-b compare func would fail for
values with the same integer value. This breaks the sorting and causes random
marker label placement.
When we receive a configure event from Wayland telling us to resize our
surface we check against the geometry constraints for the window to ensure we
do not resize below the minimum and maximum limits.
This also removes setting the FOCUSED state flag when
gtk_window_has_toplevel_focus() since this effect can now be done with the new
WINDOW_UNFOCUSED flag instead which actually works better regarding X grabs
and modal windows.
Setting state flags is actually needed here since this function is called by
GtkButton subclasses which add their specific state flags as a parameter.
This reverts commit e868b8d6ea.
Now that grab and ungrab vfuncs are implemented on GdkDevice then we can use
gdk_device_ungrab to break the implicit grab created by the button press that
triggered the resize and move.
The function definition used a pointer to the enum value rather than the enum
itself.
This broke the build on platforms that don't have an implmentation of these
functions.
This is the interface for GtkWidgets that can be associated with an
action on a GtkAppicationWindow or associated GtkApplication.
It essentially features 'action-name' and 'action-target' properties
with some associated convenience API.
This interface is implemented by GtkButton and GtkToolButton.
https://bugzilla.gnome.org/show_bug.cgi?id=667394
This lets applications block logout and similar actions ahead
of time. Currently only implemented for D-Bus, but Windows has
very similar API since Vista.
This is fairly basic, allowing applications to learn when
the session manager is about to end the session, and possibly
block this. The only implementation at this point is using the
org.gnome.SessionManager D-Bus interface of gnome-session. It should
be straightforward to port the EggSMClient implementations for
Windows and OS X.
An implicit grab is created inside GTK+ when the button is pressed down on a
window. The semantics of wl_shell_surface_resize means that you don't get a
corresponding release event that would ordinarily break the implicit grab. So
we must do it as part of the resize request.
The code for moving the menu into monitor / workarea was duplicated,
once for the push-in scenario and once for without. The problem with
the second case is that we've stored the menu position before adjusting
it. That made us remember an out-of-monitor position that then later
triggered _another_ copy of this code in the size-request implementation.
Unify this to only have one copy of code, and only store the menu
position after adjusting it to be inside the monitor. This fixes both
statusicon menus that get popped up from the panel, outside the workarea,
to not have scroll arrows, and the gedit language menu which was not
placed in the monitor at all after the initial workarea commit.
As a side-effect of this change, we now make large scrolling menus
occupy the full height of the workarea. Before this change, we were
keeping either the top or bottom edge put while shrinking the menu
to fit in the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=667249
Instead of "attribute with later start index wins, make sure the
attribute list that is merged from takes precedence. This now gives the
multiple attribute lists we use in the label an order:
1) gtk_label_set_attributes()
These attributes override everything. It's what the function's there
for after all.
2) markup of label
Other user-specified attributes come next.
3) attributes for links
When we apply custom attributes on parts of the text, we put them
last. We don't want to mess with what the user does. Also, we change
color and underline, so we usually have something to show.
- Don't compute link color attributes until layout creation
This is useful as a performance enhancement, because we don't have to
lookup the property after setting the text, so multiple markup sets
don't cost style lookups.
- Don't merge attrs into effective_attrs
We do this when applying link colors now. Keeping them separate allows
invalidating them separately.
Instead of getting confused by applied underline or color tags in the
regular markup, we store the link start/end when we actually parse the
text. As a bonus, we can avoid rescanning links when creating the
markup.
As previously announced, key snooping is something that we should not
support in GTK. In particular because AT-SPI made every key press a
synchronous DBUS call / spawned a nested main loop with the key
snoopers. This breaks responsiveness, order of key presses and internal
consistency when the AT decides to remove key events.
This patch modifies GtkPrinterOptionWidget to support loading them
again. It also allows the user to enter values from the dropdown list
to select the item.
This change follows on from a change in semantics in Wayland where calling
wl_input_device_attach with nil would make the compositor set the pointer
sprite to it's default cursor sprite.
Presently, GtkComboBoxText lets you list the items for it in the
GtkBuilder markup like so:
<items>
<item translatable='yes'>Red</item>
<item translatable='yes'>Blue</item>
</items>
but has no way to set the "id" column for added items. Add an id='' tag
for that purpose so that you can do:
<item id='red' translatable='yes'>Red</item>
https://bugzilla.gnome.org/show_bug.cgi?id=667319
When doing DnD between windows the tab label is set as the child of
the DnD info window. If this is happening the remove method of
GtkNotebook should not unparent the tab label, since it's been already
unparented, belongs to the DnD window and will be properly destroyed
when the DnD is over.
https://bugzilla.gnome.org/show_bug.cgi?id=639875
When the X server does not support the shape extension (as some
vnc implementations seem to), our DND code was always seeing
an empty input shape, so drops always missed their target.
http://bugzilla.gnome.org/show_bug.cgi?id=620240
Apparently the deprecation warning macros are placed into gdkconfig.h
during the configure stage, so put these in the pre-configured
gdkconfig.h.win32 as well, as their definitions are needed for all builds.
When switching to the compact table format, we inadvertedly lost
the 'tentative match' handling which allows to complete longer
compose sequences even if a prefix is a complete sequence.
This was pointed out in bug 666710.
This way we don't need to compute them every lookup. (That's not the
real reason though - the real reason is that I want to add new APIs that
require the caching because they return consts).
Reading a card32 property into a long may lead to undefined high
bits, so mask them off. Also, make the conditions for setting and
unsetting the stick flag opposites, to avoid unintended changes.
Patch by John Lindgren, bug 666842
The current EWMH has added 'source indication' fields to a number
of client messages. Set these to 1 to indicate a regular client.
Also fill the button field of _NET_WM_MOVERESIZE.
Previously we expect that a proxy widget holds a reference to the
action via gtk_activatable_do_set_related_action(). However, it
is possible for the widget to still be in a floating state when
it adds itself to the the action.
This is a problem when gtk_action_get_proxies() gets called, because
we return floating objects back to the user. And language bindings
aren't going to be expecting that.
Fix this by calling ref_sink() and unref().
https://bugzilla.gnome.org/show_bug.cgi?id=657367
Since we allocate the standard CSS border to the button now, and center
the child accordingly, there's no need for an additional inner-border
style property. Deprecate it and ignore its values.
https://bugzilla.gnome.org/show_bug.cgi?id=666600
==23282== 64 bytes in 2 blocks are definitely lost in loss record 8,069 of 13,389
==23282== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==23282== by 0x39A1C3E2EA: cairo_region_create (cairo-region.c:196)
==23282== by 0x6D9AF3D: recompute_visible_regions_internal (gdkwindow.c:964)
==23282== by 0x6D9B4B8: recompute_visible_regions (gdkwindow.c:1126)
==23282== by 0x6DA3450: gdk_window_hide (gdkwindow.c:5689)
==23282== by 0x6D9CED9: _gdk_window_destroy_hierarchy (gdkwindow.c:2042)
==23282== by 0x6D9D040: gdk_window_destroy (gdkwindow.c:2109)
==23282== by 0x655B5E4: gtk_entry_unrealize (gtkentry.c:3012)
==23282== by 0x7068BF3: g_cclosure_marshal_VOID__VOID (gmarshal.c:85)
==23282== by 0x706710B: g_type_class_meta_marshal (gclosure.c:885)
==23282== by 0x7066DF9: g_closure_invoke (gclosure.c:774)
==23282== by 0x7080585: signal_emit_unlocked_R (gsignal.c:3340)
==23282== by 0x707F619: g_signal_emit_valist (gsignal.c:3033)
==23282== by 0x707FB71: g_signal_emit (gsignal.c:3090)
==23282== by 0x679E243: gtk_widget_unrealize (gtkwidget.c:4458)
==23282== by 0x64E83C7: gtk_bin_forall (gtkbin.c:172)
==23282== by 0x6548BBD: gtk_container_forall (gtkcontainer.c:2014)
==23282== by 0x67A966D: gtk_widget_real_unrealize (gtkwidget.c:10253)
==23282== by 0x672D002: gtk_tool_item_unrealize (gtktoolitem.c:474)
==23282== by 0x7068BF3: g_cclosure_marshal_VOID__VOID (gmarshal.c:85)
https://bugzilla.gnome.org/show_bug.cgi?id=666552
This allows drawing calendar arrows in all possible states the main widget may
be in.
The arrow_state array is converted into a bit field since it only really needs
to store boolean information about prelight for each arrow.
We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
Deal with remote action invocations correctly by implementing
GRemoteActionGroup in the same way that GApplication does and pushing
remote activations through the before/after_emit functions of the
GApplication associated with the window.
This is the last part of getting the threading situation right.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
When we have incoming activations or action invocations we should
acquire the GDK lock, just in case the program in question is using gdk
threads.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
When parsing GMenu xml, use the facility for pick up named submenus.
Note that <section id='foo'>...</section> is _not_ a named submenu.
It is a named item with an unnamed submenu :-(
We want accelerators to work, even if the menus are not shown
locally, so we can't rely on the GtkMenu code to set them up
for us. Currently, this code only installs accelerators when the
window is realized.
This allows to specify accelerators in a convenient way, by
adding accel="..." attributes to the menu items in the
XML for the menu.
Currently, the accelerators are extracted only once, when the
menu property is changed on the application.
Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.
Put this in a separate file and substantially refactor it.
Move handling of submenu creation into gtkmodelmenuitem where it
belongs.
Improve our handling of when to show separators or not.
GtkModelMenuItem, being based on GtkCheckMenuItem, was always reserving
space for a check/radio indicator. This ends up looking pretty strange
in a GtkMenuBar.
Don't reserve space for the indicator unless it's appropriate.
This GtkMenuItem subclass (and GActionObserver implementation) contains
all the knowledge necessary for converting a GMenuModel item description
into a GtkMenuItem.
Remove much of the code that used to do this from
gtkapplicationwindow.c.
This feels premature; we do have the fallback situation covered
adaequately with the menubar, and people can do their own creative
solutions with gtk_application_window_get_menu(), so we don't have
to offer a widget for this right now.
By making "about" a per-window action, we can pop the about dialog up on
top of the correct window instead of trying to guess from the
application list of windows.
This is a GtkWindow subclass that "application windows" will use. Each
is associated with a GtkApplication, has the ability to show menus and
will have its own associated set of actions.
These were destined for GLib, but they don't really make sense as a
public API. Instead, we'll copy/paste them around between the various
codebases that need to render menus.
This is a boolean property that will be set to TRUE if the current
desktop environment is capable of displaying the application menu as
part of the desktop shell.
If it is FALSE then the application will need to display the menu for
itself.
This should be redone to show the label together with the
separator line, somehow. For now, just put the label below
the separator, as a separate item.
This should be redone to show the label together with the
separator line, somehow. For now, just put the label below
the separator, as a separate item.
This makes GtkBuilder accept a GMenuMarkup tree at the toplevel
(ie with <menu id='foo'> being a child of <interface>) and the resulting
GMenu object can be obtained via gtk_builder_get_object (builder, "foo").
We need to connect to items-changed on _every_ menu
model, which is somewhat icky. For some reason, this
works fine with a local model, but not with D-Bus in
between. Debugging needed.
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
I expect them to be used a lot, so this approach seems better than
requiring signals that connect to "notify::widget". Also, we can't use
regular functions (like dispose or constructed), becaiuse those assume
that (un)setting of the widget only happens once and with the current
design (a puble set_widget() function) we can't really guarantee that.
Also, I split them into two separate functions as one function is part
of construction and the other part of destruction of the object. And it
doesn't sound like a good idea to have that both be part of one
function.
I wanted to use weak refs to ensure this instead, but it's a performance
problem when used in the treeview and each and every cell adds a weak
ref to the treeview.
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
Dealing with disabled devices may turn into hierarchy/device
changed events on device IDs with no backing GdkDevice yet,
so protect against that. The device attachment will be handled
correctly when the device is enabled later.
Even if we can't change our sensitivity because the parent is insensitive we
should still flip the sensitive flag. Otherwise, with and insensitive parent,
child.set_sensitive(True)
...
parent.set_sensitive(True)
would result in child still being insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=666392
Instead of in the key_press handler, use a signal handler. The signal
handler runs before the default handler, and before other signal
handlers. In particular it runs before the signal handler installed via
gtk_entry_set_completion() which pops down the entry completion, and we
don't want that to happen.
The code does not change the code of the handler in any significant way,
it just refacotrs it to not call the parent anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
This was removed previously, but is necessary to support the case where
no base folder is in use, which should cause an error. This can be
experienced in save mode in the recent files list.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
That way, we can use the regular filtering features of the
filesystemmodel instead of having our own filtering function that
duplicates much of the matching code.
This also removes the broken-on-windows feature where files strting with
a dot were not autocompleted.
Use all the clever functions we invented in recent refactorings to
compute the file and dir part and the current folder.
This also fixes the bug where "./" was not taken as the current
directory but interpreted as a file named "./".
This returns the text that should be completed on. As this is somewhat
tricky to compute (and in fact one place did it wrong), let's make it a
function.
Now that we don't need to know anymore why insertion failed, we can
simplify the append function quite a lot.
A simple rule now: If we did not insert anything, beep.
Too much special code for no gain.
I did a totally unscientific questionnaire on GNOME IRC (assuming
autocompletion is for advanced users) and nobody even knew what this is.
So I suspect it's useless. Also, it's positioned completely wrong anyway
and nobody noticed so far. Last but not least, I'm trying to imitate
bash here and bash doesn't show feedback.
Use dispatch_properties_changed() instead of GtkEditable to watch for
changes to the to-be-completed text. This is necessary because various
functions in GtkEntry don't use the interface vfuncs and one only
becomes aware of them via notifications. I'm not sure this is intended
behavior, but it's how it works today.
Also, use the same code for triggering in all situations.
What the code does is this: It looks at the part of the text in front of
the cursor (or selection) and completes for it. Once the directory has
been enumerated, inline completion is activated. Note that popping up of
the completion popup is completely handled by GtkEntry.
Instead, pass the text to use to refresh_current_folder_and_file_part().
This also gets rid of the problem introduced earlier that the position
is not properly updated in do_insert_text() and therefor the completion
is wrong.
... from GtkEntryCompletion instead of implementing a poor copy
ourselves. This also makes the file chooser entry behave a lot closer to
normal entries.
This is identical to the display name when not having a path that
changes the folder. Otherwise it will have the full path that was
entered in the entry. Say when from your home dir, you type
"../../usr/li", the full path for "lib" and "lib64" will be
"../../usr/lib" and "../../usr/lib64" respectively. This value isn't
used yet, but will be soon.
The new version does not need to muck with the entry, it just extracts
the required information. It returns a reference to the folder though,
as we extract the information now instead of returning something stored.
Setter functions the way I code it look like this (in order):
1) Figure out if the value changed. If not, exit early.
2) Clear the old value (ie unref stuff, disconnect signals
3) Copy the new value
4) Set up things about the new value
This reorganization does that.
And by doing that, it even reduces the amount of code and the amount of
branches (and with it, nesting) needed.
Instead, fall through to the default handler after closing the
completion. This has the advantage of letting the file chooser entry
capture the tab key properly, so one can't accidentally move out of the
entry by pressing tab while the completion is popped up.
I also suspect it fixes bugs with weird tab keys and shift/ctrl
oddities. But who knows...
1) always emit signals
Previously, newly constructed cells would be told to not emit events.
However, we can ensure that nothing is connected to the signals, so
they will not actually emit anything.
2) don't return anything
The return value is unused anyway.
No more signal handler is needed, therefore the code can also get rid of
tracking the treemodel. And we use a faster approach for iterating the
changed cellrenderers: We just iterate all columns instead of over all
cell accessibles, as that number is likely quite a bit smaller.
We first set a NULL model and then reset the old model, just to get the
effect of clearing and then resetting.
We reset the cursor and selection afterwards, so the reset doesn't
destroy all the work we did.
Multiple changes:
- actions are now available unconditionally, but only work in the right
state. This mirrors other actions.
- instead of adding actions manually, they invoke the action on the
GtkCellAccessibleParent interface.
Tests have been updated to reflect the changes
Treat the empty string as if it was a NULL icon name instead of
rendering GTK_STOCK_MISSING_IMAGE.
This used to be the previous behavior of GtkCellRendererPixbuf and
applications might still rely on it.
We need to save the icon size locally for GtkCellRendererPixbuf, since
its properties are set again every time it's drawn (resetting the icon
size on the helper by means of _gtk_icon_helper_clear() each time).
The code is very similar; having two slightly different code paths is
bad and can lead to bugs. Refactor the code to use the same height
request function.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
If the scale has an origin (it will have one by default), GtkRange will
render the two sides before/after the current value with different style
classes, making it possible for themes to use different colors and
properties for the two areas.
This was possible in GTK 2 with style details, but got lost during the
road to 3.0.
https://bugzilla.gnome.org/show_bug.cgi?id=665140
Setup listener functions for the drag and drop events as well as the selection
events. Then create and save a data structure representing the data offer from
the other client.
This implementation is based on a hash table. The hard coded GtkSelection
atoms are preloaded into the hash table at the correct values. User generated
atoms start after the last preloaded atom.
The data device manager is a global object that provides the support
infrastructure around data devices. These data device objects are the basis
for handling drag and drop as well as selections in Wayland.
Reset state of CUPS requests correctly during authentization and
check CUPS requests for errors.
Don't initialize variables holding password and username with empty
string (#664640).
As pointed out in bug 665999, these were just not right.
Before this commit, the nicks were 'output' and 'only'.
After this commit, they are 'input-output' and 'input-only'.
In many cases we used to set focus_child to NULL all the way up
to the top and then to the right value, even if there was
a common ancestor, meaning these see a temporary NULL value for
focus_child. Only when the new focus widgets direct parent was
in the previous ancestor list did we stop early.
This fixes that by always stopping propagation when reaching
the common ancestor.
The casting used to calculate the child allocation is confusing MAX().
As a result, width and height end up with negative values, which makes no sense.
https://bugzilla.gnome.org/show_bug.cgi?id=666109
There was a corner case where the changed signal was not emitted.
If rows were built like this:
1 (not selected)
+ 2 (selected)
+ 3 (not selected)
And row 1 was removed, no signal would be emitted.
I like it when writing tests actually finds bugs that have been around
since 2003 - introduced by 4a03ea2334
actually. :)
We get certain cases, in particular with SELECTION_MULTIPLE, where we
cannot figure out in advance of real_set_cursor() if the selection will
actually change.
Previously, the cursor would just become invalid, which used to
reselect the first row in the treeview later on (without a
cursor-changed signal). This leads to a crash now with the recent
refactorings.
The patch is longer than I'd like it to be, but the situation is kinda
complicated, because we want to make sure to move the cursor to a good
row. It works like this:
1) From the deleted row, search forward for the first row that is not
going to be deleted and is not a separator.
2) If no such row exists, search backwards for a row that is not a
separator.
3) If no such node exists, clear the cursor.
Previously the code used a GtkTreeRowReference, which was (a) less
performant and more importantly (b) hiding errors.
The errors being hidden were the referenced row becoming invalid or
collapsed, because such rows would not be valid cursor rows and it would
be necesary to select a new row and emit a "cursor-changed" signal.
So if a crash bisects down to this commit, it is very likely that the
cursor has not correctly been updated and the cursor row is invalid.
This means we don't have to have hardcoded "/usr/share/wayland" to find the
cursors.
This change also fixes up the warning messages for when loading fails.
Calling gdk_keymap_add_virtual_modifiers causes _all_ virtual
modifiers to be added, which causes problem when they are co-located
on the same real modifier (as Super and Hyper often are). Effectively,
this made it impossible to enter key combinations involving Super,
since they all turn into Super+Hyper.
Move code for child allocation into the child allocation function. Don't
keep it in the overlay allocation code.
See the next commit for why this is useful.
When an implicit paint is flushed during expose, e.g. because a
non-double buffered widget is painting, make sure to copy the existing
data from the window surface we rendered before flushing back to the
paint surface, instead of using an empty base.
Code was already handling that (and said so in the comment), but only
when no implicit paint was used at all, and not in the case when it's
flushed mid-expose.
We used to only set the override color or font if it was different
than the existing value. However, that means you can't change it to
an override that is the same as the default value for the property.
With this fixed you can e.g. override with a color of 0,0,0,0 which
you couldn't before.
Previously all the commands that acted on the shell took the surface that was
to be acted on as parameter. Now we retrieve an object from the shell that
represents its state for the surface. With that wl_shell_surface object we can
then call methods on that.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
When gtk_render_arrow() is called, always add an ARROW style class to
the GtkStyleContext before rendering, so themes can specify a different
color for it.
https://bugzilla.gnome.org/show_bug.cgi?id=665420
Just always render the pixbuf ourselves and set it on the GtkImage in
the X11 case.
Code for other backends was already rendering the pixbuf manually before
translating it into a native type, so this greatly simplifies the code.
https://bugzilla.gnome.org/show_bug.cgi?id=665409
Instead of painting the window background on the grip_window we now
only paint it on the GtkWindow->window, and we make the grip_window
have a transparent background.
We can't really make transparent window handle background optional
via css atm, because the handle color is actually based on the
background color, so if that is set to transparent we won't draw
anything.
gdk_window_get_update_area is supposed to get the area where things
need painting, and remove them from the update areas. However, if
some area is covered by other windows with an alpha background we
can't just expect whatever the app choses to render in the update
area as correct, so we don't actually remove these areas, meaning
they will get correctly rendered when we get to the expose handlers.
gdk_window_move_region doesn't move children, so we can't copy
transparent child window regions with copyarea, so we remove these
from the copy region.
We track the areas that have alpha coverage so that we can
avoid using these as sources when copying window contents.
We also don't remove such areas from the clipping regions so
that they are painted both by parent and child.
This cleans up the expose handling a bit by using the existing
clip regions, and it allows us later to use painters algorithm
to do transparent windows.
If no icon size is provided (e.g. when setting icon-name or stock-id
using the GObject property directly), use the default icon size. This
matches the previous GtkImage behavior.
The new function provides an API that takes the PangoLayout and index
as input params, this way it handles strong and weak cursors internally
factoring out all code duplicated in the widgets that need to render
cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
Explicitely check the split-cursor setting when drawing the textview
insertion cursor instead of relying on the cursor_direction set in the
textlayout. This makes the cursor drawin code more uniform with other
widgets in preparation to refactoring the cursor drawing code in a
shared function.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
Move the handling of primary/secondary cursors to gtktextdisplay, which
makes code simpler and more consistent to how GtkLabel and GtkEntry
draw cursors, which is useful in preparation to further refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
GtkIconHelper is a helper object to easily obtain a pixbuf from
different icon sources (e.g. a GIcon, an icon name, a stock id, ...).
Code is ported from GtkImage, which will be adapted in the next commit.
It used to be that _gtk_path_bar_set_file() would return an error if
it wasn't able to switch to the specified file, but that hasn't been
the case for a long while now, since the file chooser became async.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Previously, when the cursor was a descendant of the collapsed row,
the cursor path was set to the collapsed row, but this was not
communicated via cursor-changed events.
_gtk_tree_view_find_path() was not a name that not really described what
the function does. And I kept forgetting it. Also, it took the tree view
as an argument and that was completely unnecessary.
Rewrite GtkSpinButton to use a touchscreen friendly horizontal layout.
Other features include:
- support for theming buttons with nth-child
- full support for RTL
- use + and - symbolic icons instead of arrows
- general streamlining and cleanup of a lot of related code
https://bugzilla.gnome.org/show_bug.cgi?id=663359
From the css docs at http://www.w3.org/TR/CSS2/box.html:
8.5.1 Border width: 'border-top-width', 'border-right-width', 'border-bottom-width',
'border-left-width', and 'border-width'
Computed value: absolute length; '0' if the border style is 'none' or 'hidden'
So, if i specify border-style none and a border-width > 0 that should give the
same result as border-width 0.
From the css docs at http://www.w3.org/TR/CSS2/box.html:
8.5.1 Border width: 'border-top-width', 'border-right-width', 'border-bottom-width',
'border-left-width', and 'border-width'
Computed value: absolute length; '0' if the border style is 'none' or 'hidden'
This is a private type, and the CSS default value is "stretch", which
is how we were parsing and printing NONE anyway.
With this fix we can use the enum stuff for printing/parsing
Various tiny semantic changes in here.
The big fix is that we consider every cell as visible and as showing if
the treeview is mapped.
This was also fixed in the tree dump test.
Also, *do* add the file to the recently-used list, even if the file does not
exist yet. This is used from the Save dialog, so even shitty apps which don't
add the file to GtkRecentManager, will get the file added from the Save dialog.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
_gtk_rbtree_reorder() was moving the node's data while reordering. As we
use the node pointer in the a11y code as a hash key, this didn't work.
So this rewrite changes that. As a bonus, it is less code and faster.
Woohoo!
- Make sure the rotated nodes aren't nil
- Use existing functions for complex computations
- Don't use NULL checks for variables guaranteed to not be NULL/nil
This has one major caveat: The new value is const, so read-only memory.
Any attempt to write to it will cause a crash. Note that we are not ever
supposed to write to it, but bugs happen...
The code used to set nil->parent, which could cause segfaults. Don't do
that. We also need to pass the parent explicitly to the fixup code,
because the node during fixup may be the nil node.
So instead of copying the children and height to the new node, we keep
the old node and copy all the old stuff to it.
This is necessary so the accessibility code can use the node as a key in
the hash table or store the node as a reference to the row instead of
GtkTreeRowReference. And because it already does that (oops), this fixes
a bunch of segfaults with a11y enabled.
gtk_rbtree_adjust() will adjust the summed values of a node and all its
parents in the tree. Currently only implemented by splitting out the
function from gtk_rbtree_free().
Instead of taking the first page and trying to adjust the rect with
random padding values, take the current page, as it's always guaranteed
to be at least as tall as inactive tabs.
This fixes some annoying 1px drawing artifacts while switching tabs when
the theme disables notebook padding.
https://bugzilla.gnome.org/show_bug.cgi?id=664494
This turns GdkWin32DragContext into a proper GdkDragContext subclass.
Because we now correctly initialize GdkWin32DragContext in
gdk_drag_context_new, we no longer crash immediatly when a DnD
operation is initialized (the find_window, drag_status, ... vfuncs
where all pointing to 0x0 instead of their proper win32 implementations).
We now try to consistently refer to GdkDragContext as "context",
GdkWin32DragContext as "win32_context" and the ole2 related
target_drag_context and source_drag_context as "ctx".
Members of GdkWin32DragContext only used by the ole2 DnD codepaths
are now explicitly marked with a ole2_dnd_ prefix.
Similar to GtkNotebook, GtkFrame was only allocating space for the
padding width, and not the border.
This could be seen by just running tests/testframe. With a theme that
renders frame borders, setting xthickness = 0 in the test draws the
button border over the frame border, which is wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=664342
Turned assertion into silent return.
This assertion is only hit when dragging from an empty tree view. In
this case, gtk_tree_view_begin_drag() is triggered from gtkdnd.c and not
from gtk_tree_view_maybe_begin_dragging_row(). We actually want to
cancel the drag at this point, but that is not possible with the GTK+
API as far as I can see.
The alternative is to not allowing the drag to start. This could be
done by simply unsetting the tree view as drag source when it is empty
and setting it as drag source again when rows are added. I didn't
choose to go with this for now, since this will likely break third party
code.
There was some regressions from the recent display line fix;
while fixing it improve the test coverage and make GtkEntry
and GtkTextView return identical results.
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
The default theme engine draws a fallback check/radio image, but
doesn't let you replace this. We now check if a background image
is set and if so render that instead of the default fallbacks.
We now support -gtk-win32-theme-part(class,part,state) in background
and border-image CSS properties. This renders the corresponding
theme part using DrawThemeBackground() and acts as a base for a
CSS based windows theme.
Note that we build the parsing code even on non-win32 so that
all themese will parse the same on all arches. We draw pink instead
of the actual theme parts on non-win32 though.
We want to move to a world where getting style properties can
allocate a new value, depending on the style property context.
In this world we can't expose "peeking" a property, as we neet
to return a ref to the property that is newly created.
So, we move the peek code into get_property and use get_property
from get_valist.
At the toplevel we have _gtk_theming_engine_get, which lets us pass
in a property context with (atm) the size to get the property for.
Then there is a lot of plumbing to push this down into the lower
layers of the style property code until finally hitting
the property resolvers.
I need this because I will be adding a property resolver for win32
theme parts, and they render differently depending on the size
(i.e. they don't scale linearly). The idea is that the code
to get the background properties will pass in the final size
and we will resolve the theme part specification to that particular
size.
If the old non-context calls are used we just hardcode a size
of 100x100.
We used to special handle gradient, but we want to be able to store
other sources (that will eventually resolve to cairo patterns).
For instance, this is needed to handle win32 theme part sources.
In gtk_tree_view_state_flags_changed() we were setting the background on
the bin_window without the necessary "view" style class, making the
treeview render with the wrong color in some circumstances (such as when
adding an empty treeview in a window, as spotted by Brian Smith).
We used to explicitly map and unmap the child GtkRecentChooserWidget when
mapping and unmapping the dialog, respectively. Now that GtkContainer actually
unmaps child widgets (instead of avoiding that), we can assume that the
child GtkRecentChooserWidget will be unmapped when we want it to be.
This fixes a warning from gtk_widget_verify_invariants(), as we were mapping
our child widget before calling our parent class' ::map() handler. Bug #659257.
Try to find keycodes for keysyms at level-0 in the keymap, but don't
fail to parse if we can find those in level-1. This fixes the
parsing of numerical keys on the keypad, which require a shift level
through Num-Lock.
https://bugzilla.gnome.org/show_bug.cgi?id=606727
This way, the a11y code knows if a column was reordered, added or
removed and can do the right things instead of trying to guess and
getting it wrong.
Also, this patch finalizes the changes so that only visible columns
exist to the accessibility interface.
In fact, invent our own function get_n_columns() which actually only
counts the visible functions, because that's the only ones we care
about.
The places where it's not used yet will be changed in the coming
patches.
.. as a replacement for _gtk_rbtree_node_find_parity(). Instead of 1 or
0, the function now returns the index of node in the complete tree
(counting from the root). And this is of course identical to the row
number.
Track the RBNode/RBTree instead of keeping a TreeRowReference. This is a
whole lot faster and less error-prone.
Also, notify the accessible of removal of rows before actually removing
them, so we have a chance to clean up.
This function returns the accessible if it already exists. This way we
can call functions on the accessible from the widget itself instead of
having to rely on signals.
Instead of requiring a special functio to be called before just removing
from the hash table. This simplifies code a lot that used to remove from
the hash table.
- Name it properly
- Make it just a set of cell_infos
Currently it's using direct hash, but as long as we don't actually
lookup stuff from it, who cares...
We implement get_cell_index() now, so it's no longer necessary.
As a side effect, we need a different index for our hash table (which
now has a wrong name, but that will soon change).
Ahem.
This is in preparation for future changes and is not meant to stay this
way. But I want to change the hash table's keys and this is way easier
when nobody is using them.
I could have tried to make GtkContainerCellAccessible implement
GtkCellAccessibleParent, but the current implementation of that
interface doesn't make sense for it.
Instead of just storing the least significant bit of the row number,
store the full row number. This will soon be useful for accessibility.
But CSS could like it, too.
Add missing GDK linking to GIR build and examples:
GISCAN Gtk-3.0.gir
CCLD gtk-query-immodules-3.0
./.libs/libgtk-3.so: undefined reference to `gdk_keymap_get_modifier_mask'
./.libs/libgtk-3.so: undefined reference to `gdk_modifier_intent_get_type'
./.libs/libgtk-3.so: undefined reference to `gdk_window_begin_resize_drag_for_device'
./.libs/libgtk-3.so: undefined reference to `gdk_event_triggers_context_menu'
collect2: ld returned 1 exit status
CCLD grid-packing
../gtk/.libs/libgtk-3.so: undefined reference to `gdk_keymap_get_modifier_mask'
[...]
https://bugzilla.gnome.org/show_bug.cgi?id=664027
The default (out) transfer mode is "full", but the passed "model" pointer gets
set to gtk_tree_view_get_model() which is "transfer none". This caused Python
programs to free the model after calling this, causing crashes.
g_checksum_get_digest checks to ensure that the passed digest_len is long
enough to hold the digest, before setting it to the actual length of the
digest returned. Digest_len is uninitialized in the code, so if you're
lucky it will be larger than 20 and everything will work fine. If you're
unlucky, g_checksum_get_digest will return either -1 or some number less
than 20, and the g_assert(digest_len==20) will fail.
Wake up the run loop unconditionally (don't check if it is waiting) because
it might go into waiting state right after we checked for it. Fixes GIMP
startup (which has a lot of GIOChannel I/O but zero NSEvents) from several
minutes to a few seconds.
(cherry picked from commit 0729cdc9a1)
We now do proper handling of existing invalid regions, and
we use ScrollDC which allows us to specify the right clip
region rather than just the bounding rect.
Positioning windows at 0,0 post creation failed, because it
was mapped with CW_USEDFAULT, but private->x/y still said 0,
so moving it to 0,0 did nothing. We now always position the
window at the right place, even when not mapped, but we
create it at CW_USEDEFAULT initially and store that position
before moving it to the right place.
This fixes the window sizing test in testgtk and the inital
position for the gimp toolbar.
The synaptics trackpad driver has some weird behaviour on scroll.
It pops up a window over the mouse pointer (looking like a scrollbar).
This has two problems:
* We get extra enter/leave events for the trackpad window
* We get back the trackpad window when we look for the window
under the mouse to deliver the mousewheel message.
So, we add some trackpad specific hacks to avoid this (sigh) based
on the trackpad window window class.
This fixes bug #542777 and was partially based on a patch there
from Peter Clifton.
gdk_flush() should gdk_display_sync() on all open displays.
Both for display_flush and display_sync it seems useful to call
GdiFlush, but we don't have anything extra to do for display_sync,
as there is no inherent roundtrip on win32.
This should close bug #84314
Windows with transients: center on parent
Splash screens: center on monitor
Also properly ignores initial moves of unmapped
windows that are not override redirect or HINT_POS
Fixes bugs #324254 and #612359
There were still cases where we didn't get a WINDOWPOSCHANGED after
a SetWindowPos() call, like e.g. with a larger minimum size than
the set size (bug #574935)
So, we revert the previous fix and now just always manually emit
a configure notify after the move_resize call. Also, we inhibit
the WINDOWPOSCHANGED configure event during the move_resize operation
to avoid multiple Configures.
There are some cases where we don't get a WINDOWPOSCHANGE such that
we generate a configure event, even if we called gdk_window_move_resize()
or similar. For instance:
* The window is fullscreen
* The window is maximized
* The specified pos/size is the same as the current one
However, as per X11 ConfigureNotify semantics we *always* want one, or
we could run into issue like e.g. bug #537296 where we're waiting for
the CONFIGURE to call gdk_window_thaw_toplevel_updates_libgtk_only().
We always get the WM_DESTROY message anyway, and we remove it there.
Bug #336416 even claims this could be a leak if the WM_DESTROY
message was not seen before the DestroyWindow call returned, as
the WM_DESTROY message could not be handled later without the
window in the handle table. I'm not sure this can happen, but we
might as well remove it.
There is no particular reason to special case this, we want to handle all
sort of normal events. The only special thing we keep is that
as an optimization we pump the message loop extra during a WINPOSCHANGED
in a modal operation as that will cause us to repaint faster.
Also, bump the arbitrary number of mainloop iterations for the timer.
I don't see why we need it at all, but at least doing more than one
iteration if needed should be nice.
When you start a window resize or move via the window menu and
don't actually change anything we're not getting an exitsizemove.
In order to work around this we also look for WM_CAPTURECHANGED.
This moves all the code from WM_SIZE, WM_MOVE, and WM_SHOWWINDOW into
one place, cleans up the code and makes sure we only send a single
configure event even if both size and position changes.
We don't pass in raise anymore, but already_mapped.
Also, already_mapped must be used rather than MAPPED, as we already
synthesize the MAPPED in the generic code (and thus we don't have
to synthesize it again).
Calling PeekMessage can cause reentrant calls into the window procedure
for sent (as opposed to posted) messages, so its not safe to call
when we're not expecting reentrancy. Instead we call GetQueueStatus
when we're just looking for availible messages.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=552041
By reverting gdk_drag_find_window_for_screen logic to what it was
before eb21a7df29.
The old logic knew how to ignore drag_window when searching
for dest_window, but that code was removed (I guess by accident).
https://bugzilla.gnome.org/show_bug.cgi?id=616544
Commit 5ebb32d1ff didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
The button highlighting in testgtk works again, even with
GDK_NATIVE_WINDOWS. Unfortunately testgtk:menus still does
not work for the forced-native-window-case.
In _gdk_window_move_resize_child it tries to decide whether to pass
SWP_NOSIZE and SWP_NOMOVE based on whether the new size and position
is different from the window's existing position. However it seems
that GDK now ends up updating the window's position before calling
_gdk_window_move_resize_child so this would mean it would think the
window never changes size or position so SWP_NOSIZE|SWP_NOMOVE would
always be set. This causes child windows to never be resized.
This patch changes it so that it never passes either flag to
SetWindowPos. I don't know whether this will cause any side effects
but you'd think it shouldn't do any harm to reassert the current size.
https://bugzilla.gnome.org/show_bug.cgi?id=628049
Signed-off-by: Hans Breuer <hans@breuer.org>
This way, we can include them without accidentally including deprecated
code. Which means we can still use the recently added turning-off tricks
for deprecation warnings.
Allows more modern browsers eg. firefox 5+ to use gtk/broadway
Auto-detects protocol version, and can switch between them at
as you connect a different browser.
This works to some extent, but seems to hang sometimes, for
instance the "button box" test in testgtk never shows up.
Don't try to remember the current keyboard modifier and mouse button
states from the last event, because that isn't always right, and don't
set event.state = 0 for generated events. Instead, add private functions
to get the current states, and implement them with API that retrieves
these states independently from an event.
Move the remaining struct definition into gtkimcontextinfo.h and include
that header in gtk.h. gtkimmodule.h is now an empty header. We should
probably deprecate it somehow.
This is also necessary so headers used in gtk .c files don't include
gtk.h which in turn includes all the deprecated headers which we want to
avoid so we can include them with deprecation warnings turned off.
Make includes not rely on gtkimmodule.h including gtk.h. This will be
important once we remove gtkimmodule from the include files.
That way, we can achieve not pulling deprecated headers automatically.
_NET_WM_STATE_FOCUSED is a new _NET_WM_STATE hint which allows us to
implement a meaningful GDK_WINDOW_STATE_FOCUSED under X11. If the window
manager doesn't support this hint we keep GDK_WINDOW_STATE_FOCUSED set since
that is what gtk+ implicitly assumed historically.
https://bugzilla.gnome.org/show_bug.cgi?id=661428
This state means that the toplevel window is presented as focused to the user,
i.e with active decorations under an X11 window manager.
If the GDK backend doesn't implement this flag, it will just remain set after
mapping the window.
https://bugzilla.gnome.org/show_bug.cgi?id=661428
By default, a background image is stretched. Instead, it is worth to
have a tiled background.
This patch allows background surfaces to be repeated or not, and should
be compatible with future extensions and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=663522
If a zero-sized NSImage calls lockfocus it throws an exception. Make sure that the image isn't zero-sized before calling lockfocus, and log a warning and return NULL if it is zero-sized.
Have the quartz version of gtk_drag_begin_idle return FALSE if the returned image is NULL.
If _gtk_quartz_create_image_from_pixbuf is given a pixbuf with size 0, 0
or which produces an NSImage with size 0.0, 0.0, it throws an exception
which Gtk doesn't handle.
your changes. Lines starting
which effectively nails down the MOD1 == ALT assumption that is valid
in all other parts of GTK+. After the modifier abstraction fixes for
OSX, the virtual mapping is now (correctly) used in more places, and
caused problems with the common default PC keyboard layout on X11 that
colocates ALT and META on the same key.
Fixes e.g. crashs when dropping from finder.
Turn the "getting_events" boolean into a counter to handle poll_func()
being called recursively, and track the loop depth correctly by
changing its counter before bailing out in run_loop_observer_callback().
This way we reallocate our autorelease pool at the right time, and
don't kill memory that is still in use by outer run loops.
Also drain, not release the pool, just for some defensive forward
compatibility.
(cherry picked from commit ef9a92d225)
Since constructors like gtk_radio_button_new_from_widget take an
instance of their type as the first argument, the gi scanner interprets
them as methods.
https://bugzilla.gnome.org/show_bug.cgi?id=661858
When an NSEvent does not have the window field set, we already assumed
the event was not for us and discarded it. But for NSMouseMoved events
we now make an exception, because such events generated after
using/clicking the main menu bar have the window field set to NULL while
the application window still has focus.
We used to experience a loss of motion events after using the menu bar,
this could be seen in buttons that stopped prelighting and first
clicks often being ignored unless you clicked somewhere else first.
These issues are fixed by this patch.
Submenus are not actually attached to a menubar, but styling them
as if they were imposes some problems (at least with Adwaita).
Just using GDK_WINDOW_TYPE_HINT_POPUP_MENU for submenus instead
fixes the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=662691
Since the wmspec_check_window doesn't have a corresponding GdkWindow we can't
rely on the get_event_window() return value to get the XID from. Just use the
XID from the XEvent directly.
https://bugzilla.gnome.org/show_bug.cgi?id=662953
When multiple pointers are in play, we need to be careful
not to loose track of the device between receiving a button
press and popping up a menu.
https://bugzilla.gnome.org/show_bug.cgi?id=663396
We have an event, so the correct thing to do is to pass
the device into the function that we are calling. GDK
just grew a variant that takes a device, for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=663444
Which handle accelerators with keycodes as well as keyvals,
so we can use it in applications that use GtkCellRendererAccel's
"Other" mode of operations (namely gnome-control-center and
gnome-settings-daemon).
https://bugzilla.gnome.org/show_bug.cgi?id=662755
I was trying to avoid including gtk.h here, but this breaks
some of our tests, and there's a good chance that 3rd party
code also relies on this include.
Instead of undefining the DISABLE_DEPRECATED guards,
define the GDK_DISABLE_DEPRECATION_WARNING macro where needed.
Also replace INCLUDES by AM_CPPFLAGS to shut up automake.
The new file defines GDK_DISABLE_DEPRECATION_WARNINGS so it can happily
use deprecated APIs.
This commit moves those functions there that use deprecated functions
and currently cause warnings.
With this commit, GDK compiles without deprecation warnings.
After consulting with Carlos, we agreed that it should be enough to grab
the core pointer instead of doing a full grab. If it turns out that's
wrong, we need to adapt the internal API for resizes to take the device
doing the resize.
As the draw handler expects the items to be laid out already, we cannot
queue a layout here to avoid a race condition with the resize that is
queued immediately after, which in turn would lead to a segfault later
in the paint_item() implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=663138
Everything that deals with a group has to be fixed.
Plus, we have NULL checks without allowing NULL arguments; since NULL
arguments are perfectly fine, we can relax the argument checks.
https://bugzilla.gnome.org/show_bug.cgi?id=662870
<row><entry>EggSMClient::quit-requested</entry><entry>instead of calling will_quit (FALSE,...) in response to this signal, install an inhibitor</entry></row>
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.
