It turns out that we do not need to have separate command lines for
running the Visual Studio preprocessor for 32-bit builds and 64-bit
builds as `_WIN64` is automatically defined by the 64-bit compilers.
This means that we can clean up the project files a bit.
GTK2 uses different gtk.def files on 32-bit and 64-bit Windows. GTK2
source tarballs ship pre-generated gtk.def for 32-bit Windows. If the
user wants to build for 64-bit Windows, the pre-generated gtk.def must
be deleted before the build to force regeneration, or it will fail to
link with 'symbol not defined' errors because the 32-bit Windows build
includes more legacy functions than the 64-bit Windows build.
While users who want to build for 64-bit Windows can delete gtk.def in
the build script, which is currently what most build scripts do, doing
so breaks out-of-source build. On AUR, MinGW packages are usually built
and packaged in the following order:
1. Run 'configure' and 'make' to build for i686-w64-mingw32.
2. Run 'configure' and 'make' to build for x86_64-w64-mingw32.
3. Run 'make install' for i686-w64-mingw32.
4. Run 'make install' for x86_64-w64-mingw32.
It fails because step 3 sees gtk.def left by step 2, which is generated
for a different build. In step 3, make sees the gtk.def change and runs
libtool to relink libgtk-win32-2.0-0.dll. libtool fails to find a lot of
necessary libraries, decides that it is not possible to build a DLL with
-no-undefined, and produces only the static library. It then tries to
relink executables with the static library, and fails with undefined
reference to 'IID_IUnknown' because -Wl,--start-group isn't used and
the use of -Wl,-luuid prevents libtool from using the correct order.
To resolve the problem, move gtk.def to builddir so different builds can
have different gtk.def files while sharing the same source tree. This
also means that the source tarball will no longer include pre-generated
gtk.def file, which should be acceptable because it is already broken on
64-bit Windows.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3029
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2684
GIMP segfaults while switching themes between dark and gray and inputting Ctrl-O
to open a file. This is because p advances past end of pixbuf in pixbuf-render.c
compute_hint() with num_channels = 3 (no alpha). This is resolved by fixing the
if statement to only check for alpha, thereby advancing p, if there is an alpha
channel.
In the Vietnamese Quoted-Readable input method, punctuation following a
base letter is converted into diacritical marks, for example a( → ă.
(See <https://en.wikipedia.org/wiki/Vietnamese_Quoted-Readable>.)
A 2008 bug report in Ubuntu argued that this is a problematic default,
particularly when typing passwords, where the effect of the punctuation
is non-obvious.
According to the bug reporter, VIQR is popular with Vietnamese users
living elsewhere in the world, where Vietnamese keyboards are unlikely
to be readily available, but is not a popular choice within Vietnam,
where the Telex or VNI input modes are preferred.
Closes: #183
Bug-Debian: https://bugs.debian.org/895043
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/191451
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Commit 6ae3082603 included some changes from the gtk-3-24 branch that
do not make sense in the context of the commit, and break the build of
GTK 2 on Windows. The delta_x and delta_y fields do not exist in the
GdkEventScroll in the gtk-2-24 branch.
Segfault occurred when displaying two windows on different X11 displays.
valgrind said:
Invalid read of size 8
at 0x4A20962: _gtk_style_init_for_settings (gtkstyle.c:398)
by 0x49ED785: gtk_rc_get_style (gtkrc.c:2036)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Address 0x70b8e80 is 560 bytes inside a block of size 1,024 free'd
at 0x48399AB: free (vg_replace_malloc.c:530)
by 0x51180D6: g_type_free_instance (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x49E98CE: gtk_rc_reset_styles (gtkrc.c:1702)
by 0x49E9A0C: _gtk_rc_context_get_default_font_name (gtkrc.c:1740)
by 0x4A20961: _gtk_style_init_for_settings (gtkstyle.c:396)
by 0x49ED785: gtk_rc_get_style (gtkrc.c:2036)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Block was alloc'd at
at 0x483877F: malloc (vg_replace_malloc.c:299)
by 0x51BD289: g_malloc (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x519F673: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x51A62BA: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x5119141: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x513563D: ??? (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x5136A54: g_object_new_with_properties (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x5136B51: g_object_new (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x49ED774: gtk_rc_get_style (gtkrc.c:2035)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Copy and update the relevant fields from the Visual Studio 2010 projects
so that we can have project files that work out-of-the-box for Visual
Studio 2019, as we did for Visual Studio 2012 through 2017.
Also update the NMake Makefiles for building the introspection files
so that we properly detect that we are building with Visual Studio 2019.
CREATEPROCESS_MANIFEST_RESOURCE_ID is a macro defined in winbase.h,
so we need an include to resolve that macro to its value, 1.
Without that it stays as a literal CREATEPROCESS_MANIFEST_RESOURCE_ID,
and ends up in the .exe file as-is, and Windows can't find it by that name,
resulting in UAC manifest not working and gtk-update-icon-cache bringing
up UAC prompt.
including when the control modifier is present, i.e. when one is typing
control-I for instance.
Orca would convert them back to the corresponding ASCII letter anyway, and
when pressing control-tab, we do want to pass "tab", not pass "\t" that Orca
would erroneously convert to "control-I".
Fixes#1743
(cherry picked from commit 728f6869cb)
This updates the introspection build process that we also check on
changes in the Makefiles when we generate the NMake Makefile snippets
and file lists, so that any changes to the source file list can be
reflected. Also ensure that we build against the freshly-built
libraries.
Make the NMake Makefiles also output the built introspection items to
the output directories of the various Visual Studio versions, according
to the build configuration and architecture, so that we avoid confusion
for different Visual Studio build configs.
In GLib-2.57.3 and later, GStatBuf may not be a struct stat on Windows,
depending on the architecture and the compiler used, so we can't just
call fstat() on the GStatBuf.
Instead, we need to use the correct CRT function to call on the
GStatBuf, which is as follows:
-_fstat32() for Windows 32-bit builds on mingw-w64 and MSVC
-_fstat64() for Windows 64-bit builds on mingw-w64
-stat() for Windows 64-bit builds on MSVC, and on all other platforms.
We are not passing in the correct architecture to the script that we use
to generate the pkg-config files for Release/x86 builds and Debug/x64
builds. Fix this.
Just link to Cairo instead of looking for the Cairo .pc file as the
Cairo build system for Visual Studio currently does not generate a
pkg-config file for us. This will eliminate the need to hand-craft a
pkg-config file for Cairo to be able to use the pkg-config files that we
generate here.
Don't pass in G_LOG_DOMAIN=\"...\" to the CFlags that is passed into the
generation the NMake Makefiles. This will avoid the introspection scanner
from choking because the resulting NMake Makefiles may not have that
CFlag escaped properly, and it is not really needed for building the
introspection binary.
Replace "stat struct" with "GStatBuf" and "stat" with "g_stat" where
appropriate to fix cross-platform issues, specifically on Windows.
Code should be identical on *nix but fixes some serious issues
on Windows:
- Field widths of "struct stat" are not constant on Windows.
If the stat function does not match the stat struct used
it will cause overwrites and undefined behavior
- The Windows stat function needs a properly encoded filename.
In many places we pass an UTF-8 encoded value which breaks as soon
as non-ASCII characters are involved.
https://bugzilla.gnome.org/show_bug.cgi?id=787772
If the name of the bookmark is NULL, using it with the printf %s format
specifier is undefined behaviour per the C Standard. Besides, it would
result in a completely unhelpful tooltip even if it were well-defined.
We already have an else case for when nothing is selected, which avoids
trying to use the name, so ensure we go there if it's NULL or empty too.
https://gitlab.gnome.org/GNOME/gtk/issues/1169
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.
We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.
This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.
Fixes#85
(cherry picked from commit 3287ac96e02ff236d74db10164c5b0c1e7b2b0bf)
(cherry picked from commit 039285deb92b6baf6ef594b0d718e8f7a7e1d0ac)
In case something happens between monitor counting and monitor
enumeration, repeat until the count matches up.
enum_monitor is changed to ignore any monitors past _gdk_num_monitors
and just keep increasing the count past that number.
GCC 8.1 added some new warnings, including warning about parentheses
with no effect in variable declarations. GTK2 headers have a few of
these, which produce a lot of warnings in projects using GTK2.
The warnings look like:
/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: warning:
unnecessary parentheses in declaration of ‘__gtk_reserved1’ [-Wparentheses]
void (*__gtk_reserved1);
^
Removing the parentheses is harmless and fixes the warnings.
When we found an icon with exactly the requested size, we'd stop
searching immediately (good), but we'd neglect to set the returned
min_difference to 0 (bad). This caused theme_lookup_icon() to
prefer other, potentially much worse, matches over the exact one.
Cherry-picked from 5aa939dc (gtk-3-22)
https://bugzilla.gnome.org/show_bug.cgi?id=792738
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
(cherry picked from commit 01455399e8)
When a project has a bundled copy of our macro included in tarball
source releases, typically in a m4/ or aclocal/ directory, aclocal
uses the serial number to determine whether the system copy in
/usr/share/aclocal is newer or older than the bundled copy. Without
a serial number, the bundled copy will always be used and will not
be overwritten, even if it is outdated.
Signed-off-by: Simon McVittie <smcv@debian.org>
glib-2.54.3 changed API, compared to glib-2.52.3 and gtk+-2.24.31's
expectations. This commit fixes the resulting issue in a backwards
compatible way.
See-Also: https://bugs.gentoo.org/650536
The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
Due to the recent changes introduced in glibc 2.27 "%OB" is the
correct format to obtain a month name as used in the calendar
header. The same rule has been working in BSD family (including
OS X) since 1990s. This simple hack checks whether "%OB" is supported
at runtime and uses it if it is, falls back to the old "%B" otherwise.
Closes: #9
Putting includes in the second argument of AC_TRY_LINK is not safe. If
a header having inline functions is included inside the main function,
it becomes a nested function. This is not supported by clang.
https://bugzilla.gnome.org/show_bug.cgi?id=792720
We need to notify ATK the description changed when the tooltip text
associated with the widget changes and gail_widget_get_description()
would use it as the description.
https://bugzilla.gnome.org/show_bug.cgi?id=779009
This custom drawing code was broken, which meant the current mode
indicator/character did not show, severely hindering XIM users.
Fix by simply removing the custom drawing and just being a GtkWindow, by
cherry-picking these two from GTK+ 3:
commit 211ccb5c73
commit c750cea4e57ed3bcb5ba7eada95d0be380aa2fe5t
https://bugzilla.gnome.org/show_bug.cgi?id=696624
Ensure that the /DYNAMICBASE linker option (which is actually the
default option) is enabled, as we inadvertly disabled it in our
projects.
Also, for x64 builds on MSVC 2012 or later, use the /HIGHENTROPYVA
linker option to improve the security of the built bianries.
Pointed out by Ignacio Casal Quinteiro.
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
…from priv->button. My refactor to g_signal_disconnect_by_data()
included this widget, when I shouldn’t have as both modes use it.
In GTK+ 3, this broke opening a CB by keyboard that was in menu mode,
if it had been in list mode initially (e.g. due to the theme).
Fix by moving to disconnect_by_func() and only removing in each mode’s
destroy() method the signals that it set on the button in its setup().
https://bugzilla.gnome.org/show_bug.cgi?id=788577
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.
Note if we do this then, as before, set the ListStore on the CB before
before appending to it, that (at least in GTK+ 3) gave warnings like:
Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed
I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.
We need floating-point division… Otherwise, only fully-on inputs can
produce any output. This fixes some of the colours wrongly being black.
While here, remove the unused rowstride variable, to shush a warning.
ComboBox warned in the doc for :row-span-column that the value must not
exceed :wrap-width, but :wrap-width does not interact with the number of
rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, & that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Rrefer to items having spans, not values, as we’re already talking about
values in the model (& rows in the menu). And clarify :wrap-width a bit.
Various disconnections had the wrong flags and/or data, so we failed to
disconnect a pile of signals, shown by 0 returned by the disconnect_*()
functions. Fix this, and use the nicer disconnect_by_*() while here.
set_transient_for(toplevel) was only called in list_setup(). It was easy
to make a test showing a NULL :transient-for instead of the correct one.
So, move the call from list_setup() to real_popup(). Also do the same
for window_group_add_window(), which means not calling it redundantly.
(I tried using a ComboBox:parent-set handler, but the Inspector’s CB
didn’t like that: it calls popup_for_device() twice and closes on button
release. Anyway, using popup() is much more concise than a new handler.)
The screen for the list-mode popup_window was only being set in
set_popup_widget(), i.e. when changing modes, so if the ComboBox was
moved to a different screen later, the popup would appear on the
original one, which is wrong.
Worse, this broke opening some combos in the Inspector in GTK+ 3.
Fix this by moving the call to set_screen() to real_popup(), so
the popup_window is put on the correct screen each time around.
https://bugzilla.gnome.org/show_bug.cgi?id=468868https://bugzilla.gnome.org/show_bug.cgi?id=786771
Bad actors, such as our very own FileChooserButton, may connect to the
:popped-up property and alter the model as the menu becomes in/visible.
We were getting an iter to the model while popped-up, then doing
popdown(), then using the iter, which may have just been invalidated by
the errant notify::popped-up handler. If so, we quickly crash fatally.
This is clearly bonkers, but until such patterns are removed, we have to
work around them. So, set_active() from the clicked item while it is
known to be valid, by moving the call to set_active() before popdown().
While here, change set_active_iter(iter) to set_active_internal(path) to
avoid pointlessly going through the iter to get the path we already have
https://bugzilla.gnome.org/show_bug.cgi?id=729651
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returns FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
caught by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
Our ::query-tooltip handler first checks whether the pointer is over any
of the icons, returning their tooltip if so, and if not chains up to
Widget::query-tooltip in order to show the text for the widget overall.
But ensure_has_tooltip(), which exists to update :has-tooltip based on
whether ::query-tooltip is needed, only set :has-tooltip to TRUE if any
icon had a tooltip, without caring whether the widget as a whole does.
That is asymmetrical and meant that if the Entry had a tooltip, but
subsequently all icons had their tooltips unset, :has-tooltip would be
set to FALSE, and hence the tooltip for the widget would become lost.
The fix is to set :has-tooltip to TRUE if the widget has a tooltip of
its own, and we only need to check the icons if that is not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=785672
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues.
Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
The TextIter is passed by pointer for efficiency. We neither need to
modify it, nor should we leave it possible to accidentally do so. So,
it should be passed as a pointer-to-const.
We do not need to go through the heavyweight process of constructing a
TextLineDisplay just to get the direction out of it, when we can simply
use TextIter API to get the text and then get its direction using Pango.
Adapted from a patch by Mehdi Sadeghi for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=779081#c20
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Mehdi Sadeghi <mehdi@mehdix.org>
Date: Sat Feb 18 02:16:00 2017 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Ori Avtalion <ori@avtalion.name>
Date: Tue Apr 20 08:06:23 2010 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
The documents state that gtk_scale_set_digits() “causes the value of the
adjustment to be rounded off to this number of digits, so the retrieved
value matches the value the user saw.” Note the lack of any condition.
But in fact, if draw-value was false, rounding was disabled on the base
Range, so values that weren’t displayed weren’t rounded. This made the
docs wrong and made an apparently cosmetic detail alter functionality.
Fix by ensuring the number of digits set on Scale is always propagated
along to gtk_range_set_round_digits(), thus rounding to it in all cases
when the value changes, regardless of whether the value is displayed.
This doesn’t address the other idea from Bugzilla: that changing the
number of digits should clamp the _existing_ value if it’s more precise.
This contradicts digits docs in the base Range, but the above from Scale
can be read as implying it’ll happen. For now, that’s an open question.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
gtk_text_iter_backward_line() checks the value of
real->line_char_offset without previously calling
ensure_char_offsets (real) to make sure the former
is up-to-date.
As a consequence of this, when gtk_text_iter_backward_line()
is called after a gtk_text_buffer_insert_range() in the
first line of buffer, the iter is not moved to the start of
the line, and the return value is wrong.
Fixed by adding the ensure_char_offsets() call.
Update the autotools scripts so that we can copy the Visual Studio
2010 and update items as necessary to obtain the Visual Studio 2017
projects.
Note that the toolset version string format has changed for Visual
Studio 2017, so a custom toolset version string is allowed and used
if specified, otherwise the toolset version string is generated as
we did before.
Note also that Visual Studio 2017 aims to be compatible with Visual
Studio 2015 on the CRT level, so it should be possible to use 2017-
compiled binaries with 2015-compiled binaries without problems.
g_file_get_path() returns the local pathname and it is entirely possible
that this pathname isn't in UTF-8 encoding, but in a different one
defined by G_FILENAME_ENCODING. Using a string in GLib file name
encoding rather than UTF-8 encoding as tooltip text will produce an
erroneous output.
Use the parse name instead. This is a UTF-8 string that describes the
file suitable for use in the user interface.
https://bugzilla.gnome.org/show_bug.cgi?id=778542
Instead of using some kind of flawed logic about modifying a keypress result
when CapsLock is toggled, just add a CapsLock shift level (and all derived
shift levels, i.e. Shift+CapsLock and CapsLock+AltGr and Shift+CapsLock+AltGr)
and query Windows keyboard layout API about the result of keypresses involving
CapsLock.
Keysym table is going to be (roughly) twice as large now, but CapsLock'ed
keypresses will give correct results for some keyboard layouts (such as
Czech keyboard layout, which without this change produces lowercase letters
for CapsLock->[0,2,3,4...] instead of uppercase ones).
Keymap update time also increases accordingly.
This is a backport of commit ca79296061 from the gtk-3-22 branch.
https://bugzilla.gnome.org/show_bug.cgi?id=165385
Throw away the gdkwin32keys.h-must-not-be-included-by-itself check,
include gdkwin32keys.h directly instead of including gdkwin32.h,
remove gdkwin32keys.h inclusion from gdkwin32.h
https://bugzilla.gnome.org/show_bug.cgi?id=775163
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
This changes the group/level semantic.
Previously W32 backend used "group 0/1" to denote "AltGr OFF/ON"
and "level 0/1" to denote "Shift is OFF/ON".
Now "group" means "keyboard layout" and there can be up to 255 groups,
while AltGr and Shift are combined into a single level enum that
takes values between 0 and 4.
Unlike X, W32 doesn't do effective group overriding, meaning that
it will never tell the caller that a different group was actually
used (even for universal keys, such as Enter), because key symbol
table is completely fabricated and there's no point in trying to
save a few of kilobytes of RAM by not duplicating universal key
records for all groups.
Also contains many whitespace changes (tab elimination, fixed
indentation) and cleanup (axed a few global variables, these are
now accessed via the default keymap).
https://bugzilla.gnome.org/show_bug.cgi?id=768722
Most people should be on GTK+-3.x by now, but in case they don't and are
using GTK+-2.24.x, we ought to "install" the gtk-update-icon-cache tool,
like we did for the 2008 builds, as it is still much used, and is already
built by the projects.
Generate the .pc files when a Python installation can be found at the
location specified by PythonPath (32-bit) or PythonPathX64 (64-bit), which
is found in gtk-version-paths.[vsprops|props].
This fixes a DOS where any app can cause all running gtk apps
to use arbitrary amounts of memory.
Originally reported against mate-panel, where running a big slideshow
in eye-of-mate caused increasing RAM usage in mate-panel.
v2: Hardcode the value
Signed-off-by: Lauri Kasanen <curaga@operamail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773587
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
We currently beep when a character is appended at the end in
overwrite mode. That is obviously not right. Patch based on
a patch by Ian MacDonald.
https://bugzilla.gnome.org/show_bug.cgi?id=772389
This is a backport of commit 260d521.
The bounding rect specifies the top left and bottom right corners - the
bottom right corner must account for the current window position.
https://bugzilla.gnome.org/show_bug.cgi?id=764996
In the preceding fix, the checks involving GDK_IS_QUARTZ_WINDOW macros
were left out. These checks are in fact crucial, because these functions
are sometimes called with non-quartz functions as the original comments
in the code do indicate. Therefore, reintroduce these checks. This
fixes a crash in GIMP.
This function can be used to check whether a GdkWindow is a quartz
window. It is equivalent to it's win32 counterpart. The function
is necessary because the macro necessary for this check is private.
This adds a set of NMake Makefiles to enable introspection building
under Visual Studio builds. As the status of introspection of GTK+-2.24.x
is considered experimental, this support is also considered experimental.
https://bugzilla.gnome.org/show_bug.cgi?id=765193
This fixes bugs with applications that try to allocate large windows,
but are not allocated the full requested size. See for example
GNOME Bugzilla #765120.
Ensure that text and selection boundaries are in a
consistent state when we emit notifications, that ::insert-text
and ::delete-text are emitted before any changes, and that
::changed is emitted after property notifications when inserting
or deleting text.
Conflicts:
gtk/gtkentry.c
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...
Conflicts:
gtk/gtkentry.c
Consider this bug:
1. Open a file chooser; switch it to $HOME
2. Start typing "~/Dow" with some file that *does* exist in your $HOME
3. Delete the inline-completion selection (e.g. the "nloads" after "~/Down").
4. While you are at "~/Dow_" hit Tab. No completion will occur.
This happens because of the following.
Say the GtkFileChooserEntry is in the process of loading $HOME,
because _set_base_folder() was called. If the entry contains no text,
then the FULL_PATH_COLUMN of the file system model will be set to
unprefixed filenames from $HOME, like
.ssh/
Documents/
Downloads/
somefile.txt
Later we avoid reloading the folder if g_file_equal(old_folder, new_folder).
However, the FULL_PATH_COLUMN gets populated in completion_store_set()
out of the actual filenames that GIO returned, plus the chooser_entry->dir_part.
If the user starts typing "~/Dow" then dir_part changes to "~/", *but*
the folder won't be reloaded since it is also $HOME. However, the completion
machinery assumes that FULL_PATH_COLUMN will contain prefixed entries like
~/.ssh/
~/Documents/
~/Downloads/
~/somefile.txt
So, we add an invariant that chooser_entry->dir_part and
chooser_entry->current_folder_file must change at the same time, and
must not get out of sync: If any of them changes, then the
completions are regenerated.
If a file system event arrives while GtkFileChooserWidget is asking the
user to edit the name of a newly created folder, the file system model
will drop the row with the editable cell, and the user will have to
start from scratch.
This makes creating new directories impossible inside a directory with a
file currently being downloaded, for instance, and it's really unhelpful
to the user because the editable row simply disappears.
We already have a mechanism in place to freeze the file system model, so
we can reuse it between the add_editable() and the remove_editable()
calls.
https://bugzilla.gnome.org/show_bug.cgi?id=729927
Conflicts:
gtk/gtkfilesystemmodel.c
The main problem is that we were emitting the row-deleted signal for the model in the middle
of the process that actually deletes the row from the model (remove the row from the array,
update the model->file_lookup hash table, etc.). In the model's caller, one of the row-deleted
callbacks was requesting an iter, which caused the model to revalidate itself - but it did
this while it was in an inconsistent state. This led to an assertion failure later when the
model resorted itself.
The fix in remove_file() is like this:
* The filteredness/visibility of the deleted node is not updated. The
node will simply be gone; we don't need to update those values at
all.
* We invalidate just the node that is being deleted.
* The model->file_lookup hash table is not completely nuked; instead,
we carefully adjust its indices.
* The row-deleted signal is only emitted at the very end, when
deletion is complete and the model is consistent.
Many thanks to William Hua for doing the detective work on this bug!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
They were in the semi-public API of GtkFileSystemModel, but never actually used outside of it.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is a function internal to the file system model; let's not pollute the gtk_tree_path namespace.
Also, make the 'i' variable into 'r' as it refers to a row index, not a file-array index (for
consistency with the docs and the rest of the code).
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way we remove paired function calls (compute/set pairs), and also make
it possible to avoid computing a filter twice, as setting the visibility
depends on filteredness.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It bothers me that we call gtk_file_filter_filter(), then negate the result,
and the return *that* from node_should_be_filtered(). So, rename 'filtered'
throughout GtkFileSystemModel to 'filtered_out' to mean things that didn't
pass the filter.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This was a copy-paste leftover from node_set_visible(). Filters are not
concerned with model freezes, so node_set_filtered() does not
need to handle freezes, either.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Make sure entering the three special strings ".", ".." or "~" in
the location entry works as expected. They already worked correctly
if you append a '/' to force them to be recognized as the 'folder'
part, but that should not be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=752707
When the file chooser changes directories, it tells the GtkFileChooserEntry to
change its base folder (i.e. the folder from which relative pathnames are resolved).
GtkFileChooserEntry then starts loading a GtkFileSystemModel asynchronously.
In the finished_loading_cb(), however, it would always ask the GtkEntryCompletion
to insert the completion prefix, since that finished_loading_cb() is what is also used
while the user is typing *in the entry*.
But when the entry doesn't have the focus (e.g. the user changed directories by double-clicking
on the file list in the file chooser), there's no reason to insert completions at all.
https://bugzilla.gnome.org/show_bug.cgi?id=672271
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since FUSE locations can be handled safely by applications show these mounted locations regardless of whether gtk_file_chooser_set_local_only()
is set to TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=586367
Conflicts:
gtk/gtkfilechooser.c
gtk/gtkfilechooserdefault.c
gtk/gtkfilesystem.c
gtk/gtkfilesystem.h
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
Conflicts:
gtk/gtkfilechooserentry.c
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.
Conflicts:
gtk/gtkfilechooserentry.c
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.
Conflicts:
gtk/gtkfilechooserentry.c
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.
Conflicts:
gtk/gtkfilechooserentry.c
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.
Conflicts:
gtk/gtkfilechooserentry.c
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.
It's very specific to the file chooser entry, so it's better kept there.
It's also not used anywhere else in the code.
Also, remove _gtk_file_system_get_folder() as it's no longer used.
Conflicts:
gtk/gtkfilesystem.h
Replace the usage of a list store and a GtkFolder with a
GtkFileSystemModel. This improves performance and reduces code size.
Conflicts:
gtk/gtkfilechooserentry.c
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.
auth_info should be a NULL-terminated array as it is used in
e.g. g_strdupv invocations iterating over its elements until
a NULL element is encountered.
https://bugzilla.gnome.org/show_bug.cgi?id=737777
(cherry picked from commit 15dbadf389)
We're seeing loops where the size of some status icons constantly
dithers between 24 and 25. Since I couldn't track down exactly
where the one extra pixel comes from, just stop reacting
to single-pixel size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
In commit 4bf5290, there isn't a prototype for
_gdk_win32_keymap_get_decimal_mark(), causing a C4013 (implicit
declaration of...) warning/error. Fix that by including the right
header for it.
1f74f12d9 rendered entry of keypad decimal mark unuseable for
several national keyboard layouts, this commit amends that, at
least for W32, and makes GTK+ behave more or less the same way
W32 behaves.
The patch works like this:
- When typing the first character at the keyboard or when switching
keyboard layouts, the decimal mark character will be cached in the
static variable "decimal_mark" within gdkkeys-win32.c
- in case of WIN32, gdk_keyval_to_unicode() asks gdkkeys-win32.c for the
current decimal_mark when converting GDK_KEY_KP_Decimal.
The first time a window is shown we should always call SW_SHOWNORMAL.
Understand whether to call SW_SHOW or SW_SHOWNORMAL and the specific
ones for the temporary windows depending on IsWindowVisible.
This also fixes the problem when calling gtk_window_present and
the window is snapped to the left or right of the screen.
This patch is based on the patches provided by Yevgen Muntyan
and Aleksander Morgado.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
If the window is iconified we want to restore the window
to get the proper size instead of showing it normal which
would change the size of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
It does no good to iterate through a series of mime types to call a
function when the eventually-called function,
_gtk_quartz_get_selection_data_from_pasteboard() in this case, gives the
wrong answer and stops the iteration on all but one especially if that
one isn't first.
The one is "image/tiff" and the quartz pasteboard function will return
any image type Quartz knows about for it, so lose the iteration and use
only "image/tiff".
This bug was also found by clang:
gdkwindow-quartz.c:1956:11: warning: implicit conversion from enumeration type 'GdkEventMask' to
different enumeration type 'GdkModifierType' [-Wenum-conversion]
*mask = _gdk_quartz_events_get_current_event_mask ();
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
This patch introduces support for using the newly introduced
monitor objects in the XRandR protocol. These objects are meant
to be used to denote a set of rectangles representing a logical
monitor, and are used to hide details like monitor tiling and
virtual gpu outputs.
This uses the new objects instead of crtc/outputs objects when
they are available to create the monitor lists. X server 1.18
is required on the server side for randr 1.5.
This patch was cherry-picked and fixed from the gtk3 branch and
squashes the two following additional fixupes:
v2: Fix primary monitor determination with XRANDR 1.5
Matthias Clasen <mclasen@redhat.com>
v3: Fix a typo in the previous patch
Matthias Clasen <mclasen@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759912
As pointed out by Paolo Borelli in bug 759436, we ought to build
gtk-update-icon-cache, "install" it and run it nowadays as it becomes more
and more common that we are going to use an external icon theme package,
so that gtk+ programs will run better and faster.
This adds support for building with Visual Studio 2015 out-of-the-box
by what we did before: copying the 2010 projects and updating items
in there to make those projects compatible with 2015, as the formats
of the project files are largely unchanged.
Use the common autotools module that was added in the last commit so that
we can clean up the various Makefile.am's in gdk/ and gtk/, and also
make more Visual Studio projects completed during 'make dist', by adding
minimal items to those other Makefile.am's. This also allows us to make
the property sheets that does the copying of headers and built items
completed at 'make dist', so that we won't have to worry too much about
headers being added (although it would be unlikely for GTK+-2.x).
This updates the autotools module copying and generating the MSVC
2012-2015 projects by copying it from from GLib, which also has the
advantage of making things work better when doing 'make -jN dist', and
the Makefile.am's in bui;d/win32/vs[11|12] have been updated accordingly.
This adds an autotools module that is copied from GLib, which is
included by the Makefile.am's to generate the complete Visual Studio
projects from their repsective templates, which:
-Cleans up those autotools files
-Make 'make -jN dist' work better
It makes sense that you should be able to type numbers that are
correctly formatted and parsable according to the current locale,
using just the keypad. This patch makes it so by translating
GDK_KEY_KP_Decimal to the decimal separator for the current locale,
instead of hardcoding a '.'.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
Replace checking if the NSView is really a GdkWindow, which will crash
in the likely event it's not a GObject, with ensuring that the parent
GdkWindow is really a GdkWindowQuartz.
Future versions of gettext will fail if this header is missing.
GTK+ 2 is not going away anytime soon, and some projects (e.g. GIMP)
want to compile it with the latest gettext.
Based on a patch by Sven Claussner <sclaussner@src.gnome.org>.
GtkPrintOperation was emitting paginate only if a signal was
connected, this meant that subclassing and overriding the
paginate vfunc lead to the unexpected result that paginate did
not run.
Instead we always emit the signal and use a custom accumulator:
if there is a signal we just run that and avoid the default
handler, otherwise we run the default handler which can be the
one by the subclass or the default handler that just skips
pagination.
Patch by Yevgen Muntyan, fixes#345345
If a drag ends inside a known window, set the dest_window field
in the drag context. This information is needed to implemented
notebook tab dragging.
https://bugzilla.gnome.org/show_bug.cgi?id=752638
The GUID of the "Install" project files happen to be the same as Pango's
"install" projects, so we need to update the GUID here so that the projects
can cooperate with each other when used in an all-in-one build for the GTK+
stack.
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
With the current code used in the m4 macro, gtk-2.0.m4 can't find
a prefixed pkg-config. This presents issue when cross compiling, as
pkg-config needs to be prefixed to work with the target being compiled
for.
Change the macro to use PKG_PROG_PKG_CONFIG rather than custom
detection code.
https://bugzilla.gnome.org/show_bug.cgi?id=749507
Add parameter for specification of port to gtk_cups_connection_cups_new().
Use default port returned by ippPort() if the given port is lower than 0.
https://bugzilla.gnome.org/show_bug.cgi?id=693738
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
Get monitor on which the most of the window is located (nearest monitor if
window is not on screen), get its work area (area not occupied by taskbar or
any other bars) and use that for maxsize.
Previous default of 30000 meant that windows maximized onto full screen,
even covering the area where taskbar is.
https://bugzilla.gnome.org/show_bug.cgi?id=726592
If a a treeview has frequent periodic additions and removals of
rows, it is possible that a page down keypress moves the cursor
out of the height of the treeview. In some of these cases, we
can be tricked into dereferencing a NULL pointer.
Bug 612919.
https://bugzilla.gnome.org/show_bug.cgi?id=746269
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.
https://bugzilla.gnome.org/show_bug.cgi?id=746064
Rename the install projects as gtk-install, to ease the integration of the
projects in a grand solution that may be used to build, for example, the
entire GTK+ stack.
"Install" the .pdb files to help people use them to debug the GTK+ stack,
or for their GTK-using applications, as they are already generated for all
builds.
Also update the copying of the DLLs, LIBs and EXEs so that we ensure that
we only copy the items from GTK+-2.x, without accidently copying items that
are not meant to be copied, or make extra copies of items in the wrong
places, such as when the projects here are used in parts of grand solutions
used to build the entire GTK+ stack.
The .pdb file name must be specified for Visual Studio 2010+ later in order
fo match the output filename if the output filename is different from the
project name. Update the projects as necessary.
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
Backport of 806c04411d to
the gtk-2-24 branch. 806c0441 was authored by Colin Walters
<walters@verbum.org>
Without this patch, the spotify linux client was crashing during
playback of some songs when using gtk+ 2.24.26
https://bugzilla.gnome.org/show_bug.cgi?id=745536
Use the /MP compiler option, where the build time for release builds can
be cut down by quite a bit. This will however cause a brief warning with
debug builds due to the use of /Gm, but the code will otherwise build
normally. Unlike the Visual Studio 2010+ builds, we can't use /d2Zi+ as
Visual Studio 2008 does not support that, so we can't get a better
debugging experience for release builds here.
Use Multiprocessor compilation which can cut down build times by quite a
bit and use the /d2Zi+ flag to have better debugging info being logged to
the .pdb for release builds.
These are only applicable for Visual Studio 2010/2012 and later.
In order to provide a constant mtime between OS build and deploy time,
while also maintaining a hardlink content-addressed model independent of
timestamps, ostree sets all mtimes to 0.
The icon cache code currently ignores directories with mtime 0, assuming
they don't exist.
Track directory existence in a more precise way.
https://bugzilla.gnome.org/show_bug.cgi?id=745052
If we fail to attach pixel data to a cairo surface, free it immediately.
We still want to cairo_set_source() the surface to popagate the error.
Spotted by Christian Boxdörfer
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
Backport of 323df2b280 to
the gtk-2-24 branch by Wolfgang Ulbrich.
When using the implicit paint pixmap, always draw to the same surface
(the standard one for the pixmap) each time rather than creating a new
one each time. This is both more effective and more natural.
It also fixes a redraw issue on win32, where using multiple surfaces
on the same HDC sometimes causes issues. This seems to be due to
leftover state on the HDC from previous surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=741060
Commit 85f2a721cf introduced an unconditional call to
gtk_widget_get_direction(). This does not work for 'foreign'
uses of the theme engine, e.g. in Qt, where widget is NULL.
This was reported as a crash in Fedora here:
https://bugzilla.redhat.com/show_bug.cgi?id=924683
Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
The function gtk_drag_set_icon_pixmap() triggered failing assertions. This was because it called the function gdk_window_get_screen(mask), where "mask" is a pixmap, but not a window.
https://bugzilla.gnome.org/show_bug.cgi?id=735005
As the Visual Studio 2012/2013 are only slightly different from the Visual
Studio 2010 projects, we can provide support for them by using scripts to
copy the Visual Studio 2010 projects, and update the specific parts as
necessary. This is being provided to help people still needing GTK+-2.x
and also to help them to transition to GTK+-3.x easier.
Thus, there would be little maintenance overhead for these as only the 2010
projects need to be kept up-to-date as a result. This might change when we
do get the stack working with WinRT/Metro, but that's going to be another
totally different issue.
We need to enclose paths containing $(BinDir) with double quotes as it
points to something like c:\foo\gtk+-x.yy.zz, which the copy command on
Windows does not like "+" in paths unless enclosed in quotes.
Since large images are in the icon cache, and apps don't tend to use that
many icons anymore, simply don't include image data and instead make apps
load files from disk. Additionally, since they're stored in GdkPixbuf data,
that means that we have to first convert them either to a cairo_surface_t,
which requires converting pixel data to be premulitplied, or an OpenGL
texture, which requires a whole GPU upload anyway.
So, even with the icon cache, the goal of icons through zero-copy, mmap()'d
data from disk just isn't doable with the icon cache format we have. The
icon cache on my disk is nearing 100MB, since we include a bunch of
high-resolution application icons, that I doubt would be used by apps at all.
Removing this inefficient pixel data makes memory usage for all applications
go down, with no speed loss.
The icon cache also, however, has an index of what icons are in each folder,
which prevents a readdir() and allows GTK+ to know what icon is where without
having to do a bunch of stat(); calls. Keeping this data is good for GTK+,
so we should still keep the index.
It doesn't make sense to remove any code for mapping pixel data from the icon
cache. There's a plan in the works to have a symbolic icon cache that does
pixel math on 16x16 icons to prevent slow SVG rendering. 16x16 pixels are
fairly small, and such images are flat colors, which should compress easily,
so the icon cache would be worthwhile here. So let's keep the code around
in preparation for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=721895
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
Although I can't find explicit documentation for clipboard pointer, it
seems to be possible to modify clibpoard memory without side-effects.
According to MSDN,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366596%28v=vs.85%29.aspx
"The global and local functions are supported for porting from 16-bit
code, or for maintaining source code compatibility with 16-bit
Windows. Starting with 32-bit Windows, the global and local functions
are implemented as wrapper functions that call the corresponding heap
functions using a handle to the process's default heap."
"Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
committed pages with read/write access that cannot be accessed by other
processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is
not actually shared globally as it is in 16-bit Windows. This value has
no effect and is available only for compatibility. "
https://bugzilla.gnome.org/show_bug.cgi?id=711553
It may happen that the received clipboard data is empty, but
if it's of type image/bmp, gtk+ will crash:
gdk_property_change: 00030AD4 GDK_SELECTION image/bmp REPLACE 8*0 bits:
... delayed rendering
gdk_selection_send_notify_for_display: 00030AD4 CLIPBOARD image/bmp
GDK_SELECTION (no-op)
_gdk_win32_selection_convert_to_dib: 1252003C image/bmp
Program received signal SIGSEGV, Segmentation fault.
0x749a9f40 in msvcrt!memmove () from C:\Windows\syswow64\msvcrt.dll
Thread 1 (Thread 2248.0x1b34):
target=0xc07b) at gdkselection-win32.c:1292
at gdkevents-win32.c:3498
wparam=8, lparam=0) at gdkevents-win32.c:232
message=773, wparam=8, lparam=0)
at gdkevents-win32.c:263
C:\Windows\syswow64\user32.dll
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
wparam=0, lparam=-1687549457)
at gdkevents-win32.c:248
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
https://bugzilla.gnome.org/show_bug.cgi?id=728745
As we are likely to have GTK+-2.x around for some time, revamp the Visual
Studio 2010 projects like what was done for rest of the GTK+ stack, namely:
-Split the property sheets, in a way like what was done for the rest of the
stack. Also clean up the resulting property sheets a bit, and update the
projects to use these property sheets.
-Use UNIX line endings for all projects and property sheets, to ease future
application of patches.
-Make the copying of config.h.win32 and gdkconfig.h.win32 into custom build
rules, so that they may be removed properly and re-copied during change
and update.
-Add a PlatformToolset tag, so if we want to support building with Visual
Studio 2012/2013, the transition can be done quite easily with a script,
such as what is now being done for the Visual Studio 2012 projects for
GLib.
As we are likely to have GTK+-2.x around for some time, revamp the Visual
Studio 2008 projects like what was done for rest of the GTK+ stack, namely:
-Split the property sheets, in a way like what was done for the rest of the
stack. Also clean up the resulting property sheets a bit, and update the
projects to use these property sheets.
-Use UNIX line endings for all projects and property sheets, to ease future
application of patches.
-Make the copying of config.h.win32 and gdkconfig.h.win32 into custom build
rules, so that they may be removed properly and re-copied during change
and update.
Similar updates will be applied for the Visual Studio 2010 projects ASAP.
Originaly the size of the window based on the client area size has
been calculated first and then variables dwStyle and dwExStyle have
been changed. Thus the window size has been calculated for different
windows type then eventually used when calling CreateWindowEx. This
caused for example the Gimp tool windows to have different size than
formerly saved in session. The whole code calculating the window size
is moved after the last adjustment of dwExStyle variable in this patch.
Signed-off-by: Hans Breuer <hans@breuer.org>
Only one bitmap can be selected into a device context. Using the
DIB created by cairo consumes the one opportunity, so every further
SelectObject into the same DC in GDK code will fail.
Can not find in the changelog entry why it was disabled at all,
see: http://git.gnome.org/browse/gtk+/commit/?id=3f4c73
The ill effect is somewhat hidden: if you try to copy images
via clipboard only the first one is pastable, i.e. Gdk keeps
the reference to the first image and provides it for later
paste.
Put dialogs and utility windows in the same level as normal and
toolbar windows so that Gtk can control their stacking instead of
forcing them, rather unnaturally, to be on top of all other windows,
even other application windows, even when another application has
focus.
Remove the 'you shall not connect' message from this signal.
While it is a keybinding signal, using it from applications is
fine and, in fact, expected.
Since update_windows list is a static variable in GdkWindow.c which
contains pointers to windows which needs to be updated, it can happen
that it contains a pointer to a window even after quit from a gtk_main().
If another gtk_main() is called in the same process it tries to process
windows in the list which leads to a crash.
Correct reference count handling of added windows prevents such applications
from crash.
https://bugzilla.gnome.org/show_bug.cgi?id=711552
The IME input method has been both ignoring keypresses of
non-spacing characters (ditching these as non displayable),
and not letting IME do anything about those.
Even though, the sparse documentation on IMM/IME seems to
hint that applications can't pipe non-spacing characters to
the input method manager, and experimentation shown that
those characters are indeed handled differently than how
it'd be expected.
Then, add basic handling of dead keys on the IME input method
itself , as it's not mutually exclusive with regular keymaps
with dead keys.
https://bugzilla.gnome.org/show_bug.cgi?id=704937
When doing updates, gtk_progress_bar_real_update can calculate
compute a negative value for activity_pos.
If the allocation width is smaller than (xthickness + size),
pbar->activity_pos will be set to a negative value and this will
cause the drawing code to emit a warning about coordinates being
out of bounds.
Prevent this by keeping the value at least 0.
https://bugzilla.gnome.org/show_bug.cgi?id=701751
The MINMAXINFO struct was being populated based upon geometry hints when
GDK_HINT_MAX_SIZE flag was enabled, then promptly having its values blown
away with default values.
https://bugzilla.gnome.org/show_bug.cgi?id=711110
Commits the pre-edit string on receipt of focus_out and reset
commands.
Patch refinements by Cody Russell <bratsche@gnome.org> and
Ek Kato <ek.kato@gmail.com>
If gdk_pixmap_new() fails (e.g. CreateDIBSection() failure) we end up
g_object_unref()-ing the temporary GdkPixmap, and we do this before having set
the drawable_impl->hdc and drawable_impl->hdc_count. Now, this could have just
been a couple of warnings being dumped, but instead it really crashes the
application because in win32-specific GdkDrawable's finalize() we assert if
drawable_impl->hdc_count is not zero:
Gdk:ERROR:gdkdrawable-win32.c:2047:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count == 0)
In order to avoid this crash, we make sure we don't decrement the hdc_count in
the GdkPixmap's finalize() unless we have it set first (i.e. we avoid hdc_count
going down to -1).
https://bugzilla.gnome.org/show_bug.cgi?id=699236
When _gdk_windowing_create_cairo_surface() gets called, we should always create
a fully new cairo surface, instead of just referencing the available one, which
may already be finished (i.e. in CAIRO_STATUS_SURFACE_FINISHED state).
A new user_data key is added to the surface to explicitly release the acquired
DC when the surface is destroyed, independent to the user_data key added to
clear the impl->user_data pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=695636
When an application translates a key event and drop its native event
before passing to imquartz, it can't recognize the NSEvent. On this
case imquartz doesn't emit any signals such as "commit" signal so
that the application doesn't insert any text. To avoid no response,
at least imquartz should fallback to slave GtkIMContextSimple.
https://bugzilla.gnome.org/show_bug.cgi?id=694273#c27
The third argument to AC_ARG_ENABLE is the action done when
the argument is specified, not when it is enabled.
This resulted in --disable-man enabling those.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
because nobody has called gdk_keymap_get_for_display() before.
Now we simply make sure the default display's keymap exists
if somebody calls any gdk_keymap_*() function with a NULL
keymap (which is an allowed value).
These files contain architecture-dependent paths, and thus placing
them into sysconfdir causes unnecessary hassle. Now the immodule cache
file is looked for in libdir/gtk-2.0/2.10.0/immodules.cache.
Belated backport of a change that was done in the run-up to 3.0.
Show printers advertised by avahi on local network. CUPS
backend now looks for _ipps._tcp and _ipp._tcp services
offered by avahi. If it finds such a service (printer)
it requests its attributes through IPP_GET_PRINTER_ATTRIBUTES
ipp request and adds it to the list of printers. Such printer
behaves like a remote printer then.
If an avahi printer is a default printer then it is considered
default by the backend only if there is no local or remote
default printer.
This functionality is enabled when building Gtk+ with CUPS 1.6
or later because it replaces browsing protocol removed in CUPS 1.6.
https://bugzilla.gnome.org/show_bug.cgi?id=702455
The file chooser does not show the hours for files modified today
when using it & hu locales on Win32. This is due to the %k format conversion
for strftime() that is in Olson's Timezone Package, which msvcrt.dll doesn't have.
Cygwin has it, though.
So for now, we just use a %H format. While %k would render
six-in-the-morning as " 6" (6 preceded by a space), %H will render it
as "06".
https://bugzilla.gnome.org/show_bug.cgi?id=560337
and not on each keystroke, which for some IMs apparently caused a full
update on each keystroke, not just a check for changes. Patch from
Takuro Ashie, bug #698183.
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
This commit is a cherry-pick from master which (sadly) fixed the issue
only after we started the 2.9x work, and I completely forgot to backport
it. This is needed because GTK 2.x started tripping the warning added in
GObject by this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Cherry-picked-from: 9f9edb662e
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
window_type_hint_to_level(): applied patch from Paul Davis which moves
dialogs to NSFloatingWindowLevel. This is not quite the perfect
solution, but it's a pragmatic fix that makes apps which have both
window types much more usable, and prevents dialog from disappearing
under an application's main window.
in pack_start(), pack_end(), clear(), also queue_resize() in
set_model(). Remove calls to queue_draw() in other functions that
already call queue_resize().
Particularly look at the source image's byte order when making a
screenshot of the "root window" (which is the window stack). Make
the code more generic so it can handle all sorts of pixel formats.
Ignore X11 errors from querying state of unplugged input devices.
GTK+ 3 handle this better with hotplugging support in XInput 2, but
this is working workaround for avoiding ugly crashes and data loss
with GTK+ 2.
When a tree view is detroyed, its GailTreeView is destroyed as well but the
weak references are kept and thus point to a freed memory block. A
segfault may arise when the model is destroyed in turn and the weak-ref
mechanism tries to clear the pointers in freed memory.
This patch removes the weak references either when the GailTreeView is
being freed or when a new model is attached to the underlying GtkTreeView.
https://bugzilla.gnome.org/show_bug.cgi?id=694711
GetLastError() should be called immediately after the failure, so call
WIN32_GDI_FAILED() just after the CreateDIBSection() error, not after
ReleaseDC().
https://bugzilla.gnome.org/show_bug.cgi?id=698563
Most likely fixes whatever evil gail interaction causing a crash I
could never reproduce but has been reported several times against GIMP.
The same fix is in GTK+ 3.x already (bug #683983).
If gdk_window_flush_outstanding_moves() creates new update area
we handle this directly in the same draw to avoid flashing.
This mainly affects win32 as X11 does its exposes from moves async.
However, its important for win32 since ScrollDC seems to sometimes
invalidate (and not copy) unexected regions.
http://bugzilla.gnome.org/show_bug.cgi?674051
Rather than set the window update region and repaint this region
when we get a WM_PAINT we just directly add it to the update
region. No need to roundtrip via win32.
This lets us also make sure we do this drawing in the same update
cycle. This seems especially important on Win7, because ScrollDC
seems to act kind of weird there, not using bitblt in areas where
it seemingly could, which makes scrolling look really flashy.
http://bugzilla.gnome.org/show_bug-cgi?id=674051
If the do_move_region_bits_on_impl causes updates they will
only be affected by the moves we haven't done yet.
We do this by making sure the outstanding_moves list is uptodate
on ever iteration of the loop.
gdkwindown-win32.c included windows.h directly rather than via gdkwin32.h
which broke the build for me at least. Instead rely on it being included in
gdkwin32.h and things work right.
This patch can be considered a leftover of commit a269c2f8d2 ,
replace the no longer existing function with the GDK function
meant to replace it.
This was noticeable on regular clipboard operations in quartz
gtk+ was trying to display already freed strings, leaking memory,
...I noticed this because I was getting weird blinking characters
as the status of my cups printers, and valgrind confirmed something
was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=683072
The GDK-Pixbuf Visual Studio 2008 project files have long been moved and
maintain in the gdk-pixbuf project, soon after that was made independent
from the GTK+ project, so these files should no longer exist in the GTK+
git repo, especially as they are no longer distributed for a long time.
Change of plans to match the tests from the previous commit.
The state of the underlying dialog is never reflected by GtkFileChooserButton's API,
as the dialog is a transient thing. The file chooser button only updates its state from the dialog,
and reflects the dialog's state, when the dialog has been confirmed and dismissed by the user.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We used to have numeric names, which are a pain to maintain when new tests are added.
Now we have a real nomenclature (see the comment at the beginning of the open-dialog-cancel-* tests),
which lets us see easily if we have tested all the combinations.
Also, added all the combinations that were missing and removed redundant tests.
Not all the tests pass currently.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The idea is that the button will only update its state of the selection and current folder
when changes to those are done either by the calling program (with the filechooser's API)
or when the user actually confirms and dismisses the underlying GtkFileChooserDialog.
If the user makes changes to the dialog but has not dismissed it yet, those changes
will not be reflected in the button (as one would expect).
This commit also makes sure the current-folder-changed and selection-changed signals
are emitted at the right times.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emitted that signal when the selection changed through the underlying GtkFileChooserDialog.
To do this when the dialog is not active and the selection is changed by the calling program
(instead of by the user), we need to wait until the GtkFileChooserButton's UI has been updated
via an async callback from GIO. So, we keep track of whether an entry point into the
button's API caused a programmatic change in the selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This should let tests complete faster. Also, this will let us test
that the correct signals are actually being emitted.
The tests now fail, as the signals are not being emitted when they
should.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Something is causing the GtkFileChooserDialog to be resized really small on the second time it is run
during each test for GtkFileChooserButton. So as a temporary hack we set it to 500x500 pixels on
the second run, so the size allocation code doesn't bomb on us.
The currently-selected file *is* the selection even in SELECT_FOLDER mode. Do not confuse this
with the current folder.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
And also explicitly remove pointer/keyboard grabs from the display.
Whenever the grab is reported lost, we should popdown the combobox, so that the
GDK_WINDOW_TEMP window is hidden and removed from the toplevel, as done with
the menu for example.
Leaving the GDK_WINDOW_TEMP window open when re-activating the application
triggers several issues in the win32 backend, due to restacking windows of the
non-toplevel group into the toplevel group:
https://bugzilla.gnome.org/show_bug.cgi?id=695200
We assumed that we didn't have to update the combo box if the dialog got cancelled,
as it should simply retain its previous contents. But this assumption doesn't work
as the dialog is brought up with the 'Other...' item - we don't want the
combo box to keep showing 'Other...' if the dialog is cancelled.
The test from the previous commit now passes.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There is this bug:
1. Start with a file chooser button in SELECT_FOLDER mode, and select a folder from the combo box.
2. Click on the button's combo box, select 'Other...'
3. You get the file chooser dialog. Cancel the dialog.
4. The file chooser button's combo box still shows 'Other...' instead of
showing the selection from (1).
This is a test to ensure that the original selection is restored.
The test fails right now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is surprisingly tricky, since the (None) item *has* to be a visible item while
the combo box is *not* popped up, so that it can show its contents. But the item
has to be *not* visible when the combo box is popped up.
Also, update the whole button's selection, not just the underlying dialog's, when
the combo box changes its selection - based on a patch by Paul Davis in
https://bugzilla.gnome.org/show_bug.cgi?id=691040#c20
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way the internal labels will show the correct selection even if nothing
has been selected programmatically.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We didn't change it when the file chooser button's dialog was inactive, and so
the actual file chooser button would not visually reflect the current selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We do some gymnastics to pull the string out of the GtkButton or the GtkComboBox that is
being used in GtkFileChooserButton to show the current selection when the dialog
is inactive - namely, we look for the subwidget with the correct ATK role, and pull its
accessible name.
Currently the test fails; this is https://bugzilla.gnome.org/show_bug.cgi?id=691040#c18
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
In the case of checking for local_only, g_file_is_native() is not useful, since it
will return FALSE for something in a FUSE mount.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since FUSE locations can be handled safely by applications show these mounted locations regardless of whether gtk_file_chooser_set_local_only()
is set to TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=586367
The file chooser button only supports single-selection modes, so
switch the code to a simpler gtk_file_chooser_get_file() to avoid
dealing with GSLists of a single file.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This may ensure that the dialog is actually done initializing. We need to kill this
sleeping business and really use signals, sigh...
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emit that signal when the user confirms the button's internal GtkFileChooserDialog,
or when he drags-and-drops stuff into the button.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This ensures that data maintained by the button while the dialog opens/closes remains consistent.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Previously we could end up in a situation where browse_list_model==NULL, and yet load_state==LOAD_FINISHED.
This is not a valid state. So, when we get rid of the list model, really ensure that we end up
in LOAD_EMPTY so nothing assumes that there is a valid list model around.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
These are generic tests that can test the button in all of its modes,
instead of hand-written tests for each combination.
Some tests fail currently.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If the user didn't explicitly select anything, BUT the file chooser button has
a current_folder set, do the same as what GtkFileChooserDefault would do:
return the current folder as the selection.
This makes the tests in tests/filechooser pass!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If no file was originally selected in the GtkFileChooserButton, then its
internal dialog is brought up and cancelled, then we need to restore the
selection back to none. GtkFileChooser, though, doesn't like to
select a NULL file, so call _unselect_all() in that condition.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The button's underlying file chooser dialog should not be used to store the file selection
while the dialog is unmapped. Instead, the file chooser button now stores the
selection itself.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to fetch a possibly multiple selection from the GtkFileChooserDialog, and then
pick just the first item from the selection list. But since GtkFileChooserButton
operates in single-selection mode only, it can simply use gtk_file_chooser_get_file()
instead.
Also, the right way to reset the selection for GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
is with gtk_file_chooser_select_file(), not with _set_current_folder_file().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The file chooser is asynchronous, so doing 'select_file (old_file)' and subsequently querying
the file for updating the labels is not going to work. However, the underlying file chooser
will emit 'selection-changed' as appropriate when it finishes restoring the old file. So,
we only need to update the labels when the file chooser dialog is confirmed, not cancelled.
This code came from a home-grown testing mechanism, which didn't aggregate tests
into a test suite; it just ran them one by one. Here we move some of that machinery
to GTestDataFunc for more flexibility in running tests.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
With the binutils-gold linker the '--no-copy-dt-needed-entries' flag is
active by default and using any symbol from indirectly loaded libraries
will result in undefined reference errors.
https://bugzilla.gnome.org/show_bug.cgi?id=692810
gtk_menu_shell_insert() is a virtual function that was being directly
invoked from the class vtable.
Turn it into a proper signal and emit it in the usual way.
See https://bugzilla.gnome.org/show_bug.cgi?id=656565.
This is a backport of Ryan Lortie's commit
05aeaeef9e from the GTK+ 3 branch.
Normally, the xthickness in the style maps to the space on the sides of
the widget, to accommodate for its border - GtkEntry's text area
background width is calculated as (allocation->width - 2 * xthickness),
and the border is rendered in that area.
GtkSpinButton has an additional panel for the buttons though, which will
render the right-side (left-side for RTL) border itself, taking
xthickness into account. This results in the xthickness for that side
being applied twice, both to the spinbutton panel and to the entry's
text area.
Visually, a slice with no painted background can be seen in spinbuttons
on the right side (left side when RTL) of the text area, where the
border would be rendered by the entry, which looks bad.
This patch makes GtkSpinButton render the same background of the entry
in that slice, to compensate for the xthickness being allocated to the
button panel instead.
https://bugzilla.gnome.org/show_bug.cgi?id=683511
When state-hint is TRUE, GTK_STATE_ACTIVE was used to paint the entry
background and frame, since commit
207f3f8685.
Given that everywhere else in GTK2 - including GtkEntry itself in
draw_text_with_color() - GTK_STATE_ACTIVE is used for non-toggleable
widgets to indicate selected but not focused text, this leads to the
entry painting itself with the wrong background color when focused.
This is unsolvable from the theme, as changing the ACTIVE background
color to be the same as NORMAL would give a wrong background to selected
but not focused text as per above.
This patch avoids using GTK_STATE_ACTIVE to paint GtkEntry's background,
changing the code so that the widget state is always used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=692554
The old code to load the last_folder_uri state from the settings was not actually
ensuring that the settings were read from disk. The result was this:
1. user chooses a folder in SELECT_FOLDER mode
2. user dismisses the file chooser dialog inside a GtkFileChooserButton
3. The dialog unmaps itself and saves the last_folder_uri with the user's selection
4. The file chooser button gets queried for the selection
5. GtkFileChooserDefault sees that it is unmapped, and falls back to the last_folder_uri
6. But since that key is not ensured as read by the temporary instance of GtkFileChooserSettings,
it returns nothing.
7. The file chooser falls back to returning the user's home directory.
However, *we don't use the last_folder_uri* anymore, for anything! So, removed
that code and now everything falls back to ->current_folder correctly. This
is the correct selection value for SELECT_FOLDER mode anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=674556
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
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).
Need to check targets and get_func in each loop iteration because
calling get_func the fist time might do whatever to the clipboard.
Re-fixes bug #626499. Also free the target table after we're done.
Replace long obsolete AM_CONFIG_HEADER with proper AC_CONFIG_HEADERS.
automake-1.13 errors out upon seeing former.
Similarly remove AM_PROG_CC_STDC. It's proper replacement, AC_PROG_CC,
is already present.
Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
...so that we will include the correct gdkconfig.h, which would be
in $(srcroot)\gdk\ during the Visual C++ build.
Also prepare support for Visual Studio 2012 in this project, so it would
be easy to use a script to copy and replace the necessary items in the
Visual Studio 2010 project set to make it a Visual Studio 2012 set.
We must not release the GtkClipboardOwner in pasteboardChangedOwner
becaue we don't own a reference to ourselves (NSPasteboard does).
Instead, release the owner right after setting it, transferring
ownership to NSPasteboard
Also, fix repeated setting of the same owner by keeping the
owner around in GtkCLipboard, and re-use it if "user_data"
doesn't change. To avoid clipboard_unset()ting our own contents
in the process, add an ugly "setting_same_owner" boolean to
GtkClipboardOwner, set it during re-setting the same owner,
and avoid calling clipboard_unset() from pasteboardChangedOwner
if it's TRUE.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2010 project file to build libwimp as a
standalone module/DLL, and the property sheets, .sln file and
gtk.vcxprojin/gtk.vcxproj.filtersin/install.vcxproj are updated
accordingly so that the needed stuff get built properly and go
to the proper places for the Windows Themes to work correctly
with the Visual C++ builds.
Thanks to nus for pointing this out.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2008 project file to build libwimp as a standalone
module/DLL, and the property sheets, .sln file and gtk.vcprojin are updated
accordingly so that the needed stuff get built properly and go to the
proper places for the Windows Themes to work correctly with the Visual C++
builds.
Thanks to nus for pointing this out. Visual C++ 2010 projects files will
be updated in the next 1-2 days.
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
Per the gtk-devel meeting on 2012/11/29, we'll not have a UI in the file chooser dialog
to select between those modes. Instead, we'll show that key in gtweaktool.
This reverts commit 7860500bc6.
Both flashing a window and setting the window opacity were using
incorrect declarations for function pointers. They were missing the
WINAPI annotation as defined in windows.h. As a result, the stack
could be corrupted when these functions were invoked.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=689235
Be a bit more careful in get_pango_attr_list() and
get_utf8_preedit_string() to ensure that the client_window is properly
created before proceeding, to avoid access violation/segfault crashes on
Windows with IME installed, especially when running the pickers demo.
https://bugzilla.gnome.org/show_bug.cgi?id=682919
(cherry picked from commit a866ed7378)
In gtkimcontextime.c, use gdk_win32_window_get_impl_hwnd() to get to
the impl's existing native window instead of GDK_WINDOW_HWND() which
implicitly ensures a native window for the widget itself. This seems
to work around whatever GDK problem with native subwindows and fixes
the bug.
Activate the "hides on deactivate" behavior for splashscreens,
torn-off menus, utility windows, tooltips and notifications: when
another application is brought to the front, these windows are hidden
so as not to obscure it. This is the expected behavior for
application-specific floating windows on OS X.
When GTK+ runs with inputim-ime.dll module, there is NULL
pointer reference. Because "context_ime->client_window" may
be NULL in gtk_im_context_ime_reset.
https://bugzilla.gnome.org/show_bug.cgi?id=644906
(cherry picked from commit 74f57ee04d)
Based on a patch from Paul Davis, inject synthetic enter events directly
into the Quartz event stream, instead of trying to synthesize them in GDK.
This seems to magically fix most combo box popup weirdness, I guess
some code is relying on a specfic order of events, or any other state
imposed by the "proper" code path of events coming in the usual way.
The patch also removes _gdk_quartz_events_send_enter_notify_event()
which is now obsolete.
so they can appear on top of popup menus. Also, reorder the switch()
statement in window_type_hint_to_level() so it resembles the stacking
order, to avoid confision like this in the future.
The call to scrollRect: must be accompanied by a call to redraw the
newly exposed area, otherwise the scrollRect: will have no effect.
Secondly, compute the newly exposed area correctly.
Thirdly, also expose the lower window border or the area moved from
the lower window border if applicable, to make sure rounded corners
are properly drawn or don't leave garbage.
Don't try to handle button press events on the window frame, they
have out-of-window coordinates. Also, break grabs on such events
so popup menus go away.
Patch from Kristian Rietveld, fixes bug 684419.
which does not really have a different effect than the previously
used NSPopUpMenuWindowLevel, but is what all code examples I found
are using, and it does make more sense.
Application code can set shortcut folders that are already bookmarks.
This code causes the bookmarks to be refreshed after the shortcut is
added removing any possible bookmark duplicates
https://bugzilla.gnome.org/show_bug.cgi?id=577806
Don't just unref the completion_store, call discard_completion_store()
instead which also unsets it as the GtkEntryCompletion's model. Fixes
bug 681845 and probably some others, because the situation in this bug
is completely common.
because the user_data is the GtkTextView. This used to crash when the
text view got destroyed, and the buffer was used for another view.
Fixes bug #652204.
Will read from old location if new location isn't found, and will always
write back to the original location the file was read from.
Adapted from commit ceb3fecd11 on the
master branch, based on a patch from
William Jon McCann <jmccann@redhat.com>
GdkPixmapWin32 allocates a cairo_surface manually for non-foreign
pixmaps, instead of letting GdkDrawableWin32 create on on-demand.
However, the pixmap created surface is a strong ref, rather than the
weak ref created by gdk_win32_ref_cairo_surface() so we can't rely
on _gdk_win32_drawable_finish to actually free it. So, we have to
manually free it when we finalize or we leak it.
https://bugzilla.gnome.org/show_bug.cgi?id=685959
Before we used a window's background color, which resulted in corrupted
display in some cases, presumably because we didn't reset the active
pattern. This patch seems to eliminate the observed corruption.
It is better to install these under gdk2/ and gtk2/, to make
it explicit what version they are about. Doing this will eventually
let us move the gtk3 docs to gtk/.
Apply patch from Kristian Rietveld which addresses two issues
in gdkeventloop-quartz.c:
This patch moves the autorelease pool drain and introduces protection against
the invalidated ufds. Basically, when we suspect ufds has been invalidated by a
recursive main loop instance, we refrain from calling the collect function.
This makes sure that if the gtk-im-module setting changes we update
our internal state immediately on the next event whichever it is.
In particular this fixes the case of the gtk-im-module setting
changing while the user is typing and the slave context remaining
the same, effectively ignoring the setting change.
Backport of a0f155e839.
https://bugzilla.gnome.org/show_bug.cgi?id=675365
A change in xkeyboard-config 2.4.1 made it so that function keys
now have a shift level which has the same symbol, but 'eats' the
shift modifier. This would ordinarily make it impossible for us
to discriminate between these key combinations.
This commit tries harder to discriminate in 2 ways:
- XKB has a mechanism to tell us when a modifier should not be
consumed even though it was used in determining the level.
We now respect such 'preserved' modifiers. This does not fix
the Shift-F10 vs F10 problem yet, since xkeyboard-config does
not currently mark Shift as preserved for function keys.
- Don't consume modifiers that do not change the symbol. For
the function keys, the symbol on the shift level is the same
as the base level, so we don't consider Shift consumed.
For more background on the xkeyboard-config change, see
https://bugs.freedesktop.org/show_bug.cgi?id=45008https://bugzilla.gnome.org/show_bug.cgi?id=661973
It replaces the recently added GtkRange:primary-button-warps-slider
style property. Implement the setting in the quartz backend,
it proxies the "click in the scroll bar to" property from the
OS X PrefPane.
cc7abf6a1c introduced the
primary-button-warps-slider style property, but with a different
condition check than the GTK3 counterpart.
It turns out we really need to check for the mouse click location here,
or we'll warp the slider to pointer also in case we clicked on the
slider itself.
https://bugzilla.gnome.org/show_bug.cgi?id=683512
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
A call to scrollRect must be followed by a call to set that the offset
rect needs display for the changes to "take effect". This was not
done prior to this patch which, in some cases, caused corruption during
scrolling.
get_time_from_ns_event(): apply patch from Michael Hutchinson which
makes sure the returned guint32 wraps correctly on 32 bit machines
when the uptime exceeds 2^32 ms.
(cherry picked from commit 78506bd604)
This was showing up when using a combo box in list mode. After popping
up the list, the keyboard grab appeared stuck. What was stuck here is
only the client-side grab, since we forgot to clean up our grabs
when receiving an UnmapNotify.
This bug was introduced in 3f6592f60f.
[ Alexandre Rostovtsev <tetromino@gentoo.org>: backport to 2.24 ]
https://bugzilla.gnome.org/show_bug.cgi?id=680346
Add a GtkRC option to select for an LTR/RTL widget direction in the
pixbuf engine; this will allow the engine to apply different theming
assets according to the text direction, which is useful when theming
e.g. a spinbutton or a combobox entry.
Implement a special case for the root window, which has to be handled
differently on OS X.
Contains some bit fiddling corrections by Kristian Rietveld.
Beforehand, the check whether or not emission is necessary was done
based on the "uninitialized" window position in the top left corner.
We now wait until the window size is set for the first time, to avoid
emitting EnterNotify when it is not necessary.
Accept a :-separated list of module names in GTK_IM_MODULE and
the corresponding setting, to deal a bit better with broken
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=603559
Patch by Akira Tagoh, backported from GTK+ 3. The backport
is required because GTK+ 2 and 3 are listening to the same env
vars and settings for immodules.
Demos in gtk-demo are supposed to be exemplary. However, if one were to
give them dummy main functions many of them would not compile with
-DGSEAL_ENABLE. This changes the demos to make them use accessor
functions whenever possible instead of direct changes to the struct
members.
http://bugzilla.gnome.org/show_bug.cgi?id=667155
Explicitly return FALSE in selection_set_compound_text() to
indicate that we don't want to support compound text selections;
this will eliminate the "not implemented" warning for quartz.
This pushes the clipboard contents to the OS X clipboard when the
application is quit. Without doing this, clipboard data set by a GTK+
application cannot be accessed after the clipboard has been quit.
Currently, we implement this the easy way because the clipboard
support is fully implemented in GTK+. In the future this might change.
Before, right click events were still let through into GDK. In this
case, also middle/right button events with x-coordinates in the range
[-3, 0] are processed, resulting in failures/crashes in the window
finding code because no GdkWindows are present in this range.
Turn dead_doubleacute plus space into '"' and not into a double
acute because that's the way to enter double quotes on the
US-International keyboard layout.
The window's role is 'GtkFileChooserDialog', so that window managers can match it
for positioning.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Having refactored cups_request_printer_list_cb so that the cups
version-dependent block size is small enough to be handled in a single
ifdef, make the ifdef HAVE_CUPS_API_1_6 block
So that it can be passed as a single parameter to functions as we
extract-function to make cups_request_printer_list_cb more manageable.
Note that not all of the affected variables are changed in this
changeset. Those are in extracted functions and will be addressed in the
next two changes.
In GTK+ 2, child widgets don't get unmapped, and yet, that is when we were trying to
save the settings of GtkFileChooserDefault. Now we connect to the toplevel's
unmap signal and do the right thing there.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Of course, we must pass coordinates in the NSWindow coordinate system
when creating an NSEvent. This fixes drag icon positioning and makes
the icon slide back to the correct position when the drag is
canceled.
In the Quartz backend, there are two methods by which windows are
resized. The first method is fully handled by Quartz and does not appear
in the event stream the application resizes. The second method is when
we resize windows by ourselves. In OS X this happens when a GTK+ resize
grip is used. This resize grip is larger than the Quartz resize grip.
When the resize is started outside the "Quartz area", we have to handle
it by ourselves.
This patch fixes this manual window resizing by ignoring events while we
are in the process of resizing (such that the events actually arrive at
the sendEvent handler of GdkQuartzWindow where this resize is handled).
When the resize has finished we break all grabs such that GDK is not
stuck thinking the cursor is still in the resize window.
When GtkPrinterFunc always returns FALSE, for example when looking for
a non existent printer, if print list is done for all backends or print
backend status is UNAVAILABLE, gtk_enumerate_printers() finishes with an
empty backend list and destroy function is never called. We need to
check the backend list again after calling list_printers_init for all
backends and finish the enumeration if it's empty.
https://bugzilla.gnome.org/show_bug.cgi?id=672125
As dieterv said, gtk 2.24 win32 binaries have been frozen on
glib 2.28.x, and we dont have resources rigth now to ensure pygobject
static bindings still function correctly with newer glib versions
If the Window Manager supports the _NET_WM_STATE_HIDDEN, we use it to use
the _NET_WM_STATE protocol when de-iconifying windows (iconification is
unchanged, via XIconifyWindow). Additionally, we no longer interpret all
UnmapNotify events for our window as the result of iconification.
(Based on patch by Tomas Frydrych <tf@linux.intel.com>)
The F keys have no unicode mapping, and UCKeyTranslate() returns
a bogus 0x10 as mapping to unicode. Instead of checking for this
random and undocumented return value, simply assign all function
keys explicitly. This patch also splits the ill-named "known_keys"
array into "modifier_keys" and "function_keys" which is much
more obvious.
_gdk_x11_keymap_key_is_modifier() never tries to set min/max_keycode
if they haven't been set before, meaning that until another function
sets those, all the keys will be seen as non-modifiers.
This causes GdkKeyEvents to be wrongly tagged with "->is_modifier = 0"
when in actual fact the key is a modifier. This fixes keyboard
shortcuts captured with GtkCellRendererAccel in "raw" mode thinking
a modifier without any actual keys is a valid shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=670400
Conflicts:
gdk/x11/gdkkeys-x11.c
This commit fixes crash which occurs in Firefox, Thunderbird and Inkscape
during printing. This crash was caused because of wrong handling of Custom
CUPS options. (#543520)
When calling gtk_window_present(), gdk_win32_window_raise did not
actually raise the window anymore. Replacing BringWindowToTop() with
SetForegroundWindow() fixes this.
During testing, we also discovered that sometimes SetForeGroundWindow()
will (correctly) refuse to raise the window and fail(for example: sometimes
when dragging a different application at the time of a gtk_window_present()
call). To prevent a GdkWarning from being produced, usage of the API_CALL
macro has been removed for this case.
Additional goodies of SetForeGroundWindow:
- it brings the window to the front when the process owning the
window to raise is the foreground process (for example when
gtk_window_present is called from a GtkStatusIcon's activate
signal handler)
- it limits itself to flashing the task bar button associated
with the window if the process owning the window to raise
is *not* the foreground process (for example when gtk_window_present
is called from a g_timeout_add callback function)
https://bugzilla.gnome.org/show_bug.cgi?id=665760
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.
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.
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
We add _gdk_offscreen_window_get_real_drawable to get the real
pixmap impl for offscreen windows, then we use this
in gdkgc-win32.c:get_impl_drawable() for offscreen windows
This fixes a crash when rendering win32 theme parts on
offscreen windows (bug #623563)
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>
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.
But use the orientable interface instead. This has already proven
usefull for GtkVolumeButton widgets (see previous commit) so apply
the same logic all over the place.
The trough was being rendered horizontal for vertical
GtkVolumeButton widgets. Not relying on GTK_IS_VSCALE
but using the orientable interface instead fixes this.
Expanders are usually drawn as little triangles and unfortunately
do not support rotated drawing modes. So a hack is applied (see
gtk_tool_item_group_header_expose_event_cb for details) when
drawing a GtkToolItemGroup's header for horizontal GtkToolShells,
forcing the triangle to point in the right direction. Except we
don't draw expanders as triangles on Windows. Usually, expanders
are represented as "+" and "-". It sucks for "+" to become "-" and
the inverse when we don't want to, so reverse the hack here.
Active buttons have not had their contents (icon & label)
displaced ever since uxtheming became available in Windows XP.
We still care about this displacement for classic themes
though (even on Vista/7 where classic themes are used to
implement High Contrast support).
This reverts to the old dibsection creation code for 16bit depth.
This makes the non-cairo stuff work, we then access the bits as
a cairo image surface, which isn't 100% right, but might be good
enough.
Fixes bug 665013
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()
It makes GtkIconView segfault on GTK 2.24.
gtk_icon_view_expose() calls gtk_icon_view_layout() first thing if
there's a layout queued anyway, so we wouldn't end up in the same
situation causing the crash the original patch is supposed to fix.
This reverts commit 5a03f4a6a5.
https://bugzilla.gnome.org/show_bug.cgi?id=663138
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.
When running with GDK_DUBUG="draw", gdk_win32_draw_rectangle
calls _gdk_win32_drawable_description, which calls
gdk_drawable_get_size for a GdkWindowImplWin32.
gdk_drawable_get_size then tries to call
GDK_DRAWABLE_GET_CLASS (drawable)->get_size, which points
to NULL for GdkWindowImplWin32.
Adding the missing drawable_class->get_size implementation
fixes this.
The cairo context was always created but only ever used
and destroyed(!) in the second if block (!GTK_IS_PANED (widget))
so moving around the gdk_cairo_create call would have
been the obvious fix.
However, said if block is not used at all, so clean
up draw_handle instead.
https://bugzilla.gnome.org/show_bug.cgi?id=663543
The win32 code for GdkPixmap dib creation workes as such, but
when creating a cairo surface for it with cairo_win32_surface_create
from the HDC it fails for any bitmap format than RGB24, due to
assumptions in cairo.
In order to create a cairo surface for e.g. A1 formats we need
to let cairo create the surface via cairo_win32_surface_create_with_dib.
Additionally, we must then make sure to use this surface in
gdk_drawable_ref_cairo_surface, and to not create a new HDC for
it but reuse the cairo one (as only one HDC can write to a bitmap).
Even with this fixed there are some issues with current cairo, as
cairo A1 format isn't quite the same as win32 monochrome bitmaps.
Fixes for cairo will be submitted.
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.
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
We simply use the Tracker DBus api here, caching and direct
access that come with libtracker-sparql are probably not needed
here. Based on a patch by Martyn Russell.
https://bugzilla.gnome.org/show_bug.cgi?id=658272
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.
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.
(cherry picked from commit ac943bf69a)
When scrolling a window partially obscured by another window,
artifacts of the obsuring window where being blitted into
the newly scrolled position. In other words, BitBlt copies
the covered region (basically garbage instead of what we want)
and does not cause a repaint (unlike how XCopyArea behaves).
Replacing BitBlt() with the old ScrollDC gymnastics (removed from
blit_inside_window() in commit e96a41be45)
when being passed a Window for blit_inside_drawable() makes these
artifacts go away.
Thanks to Alexander Larsson for figuring out the cause and
pointing out possible solutions.
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.
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.
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_WINDOW_HWND() calls from outside gdk calls ensure_native_window,
but we really want the HWND of the impl window, so call
the new gdk_win32_window_get_impl_hwnd() instead.
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).
The ms-windows engine incorrectly displays notebooks: the
tabs are not attached to the body, and look more like
regular buttons than actual notebook tabs. Also, the frame
around the notebooks is also incorrectly drawn.
https://bugzilla.gnome.org/show_bug.cgi?id=650300
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
When compiled with older SDKs, the original change for this bug caused a
compiler warning about NSWindow not being able to handle a setStyleMask
message. This tricks the compiler into thinking that it can.
and use it in stock items and GtkAccelGroup. Change the non-virtual
one to MOD2 on OSX, so hardcoded accelerators in the IM context and
the treeview work.
gdk_unicode_to_keyval(uc) returning (uc | 0x01000000) is not an
error return value but simply the way to encode 24-bit unicode
characters directly as keyvals.
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
Create a synthetic NSMouseLeftDown to store in the GtkQuartzDragSourceInfo
rather than relying on the NSWindow's latest event being the right one (or the
right kind).
Clear the Drag paste board just before the info->context is released.
This way the GtkDragSourceOwner is released just before the drag context
is and thus can pasteboard:provideDataForType: not accidentally access
an already released drag context
Move destruction of child widgets from finalize() to dispose()
because unparenting emits a signal with old_parent as object
parameter, which tries to ref the toolbar that is being
finalized.
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
which are SHIFT and MOD2 on the Mac, and SHIFT and CONTROL otherwise.
Use the new define all over the place and rename variables and
members to not say "shift" or "control".
Introduce <Primary> in accelerator strings, which resolves to
GDK_CONTROL_MASK on X11/Win23, and to GDK_META_MASK on quartz.
Also serialize CONTROL/META as <Primary> depending on the platform.
Handle dead keys in special_ucs_table and have them converted by
UCKeyTranslate(), so all dead key combinations can be entered.
Later, this should be handled in the input method, just as it's
done for X11/Win32.
This contains the fixes to centralize the handling of the pathbar, recent-files widgets,
and filename entry - the entry would sometimes be missing before these fixes.
This also contains a fix to the recently-used mode, so that the file list is indeed
sorted in newer-to-older order.
This fixes a regression introduced in commit
b1a1685a33eca16979e63d79915395af0b36. gdk_visual_get_*_pixel_details()
should not be called with a NULL visual.
https://bugzilla.gnome.org/show_bug.cgi?id=649588
We used to get an implicit -lm from gdk-pixbuf, but that has
recently been changed to not inject extraneous libraries into
link lines, so we have to do it ourselves now. This is more
correct, anyway.
There's no real asynchronicity going on, anyway, so let's do both within
a single iteration of the idle handler.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The mtime from GtkRecentManager may not the same as the file's actual
mtime, so the final result could appear unsorted to the user. Instead,
we will let the view do the sorting.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
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>
I tried to suppress compiler warnings on pre-10.6 machines this way,
but it defeats its purpose when you compile for pre-10.6 machines on
a 10.6 machine. For now, we have to live with the warnings when
compiling on/for pre-10.6 machines, there does not seem an easy and proper
way to suppress the warnings.
In GtkClipboardOwner pasteboard:provideDataForType do not call
_gtk_quartz_set_selection_data_for_pasteboard() is selection_data.length
is smaller than 0. The function relies on having a positive length,
since it stores the length in a uint ...
-Added Visual C++ 2010 project files. They are like the VS 2008 projects
where the GDK and GTK+ projects are filled-in templates, which are filled-
in during 'make dist', and added related README.txt file, and add them
into distribution
-Updated the VS 2008 README.txt to reflect the latest situation regarding
dependencies etc.
-Updated README.win32 to tell people about the now-available VS2010 projects
-Updated config.h.win32.in as VS 2010 ships with stdint.h
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>
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.
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 'LastFolderUri' settings 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>
At http://dev.laptop.org/ticket/10643 we are seeing that drag-and-drop
within the Sugar shell causes all of Sugar's custom keybindings to be
removed.
This is because gtkdnd tries to unbind XK_KP_Space, which (on my systems)
is resolved to NoSymbol by XKeycodeToKeysym(). NoSymbol has value 0,
the same as AnyKey, and XUngrabKey(AnyKey) is equivalent to unbinding
all possible keycodes.
Fix this by catching NoSymbol before binding/unbinding.
https://bugzilla.gnome.org/show_bug.cgi?id=652402
For client-side windows, we need to queue a repaint when the background
changes. For native windows, the windowing system does take care of it,
but client-side windows are our own, so we gotta do it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=652102
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!
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.
GAIL now supports the has_entry property for combo boxes, but the old
GtkComboBoxEntry class does not use this property, so GAIL has not been
supporting it correctly in 2.24.
http://bugzilla.gnome.org/show_bug.cgi?id=637304
This adds missing annotations for gdk_window_get_position(),
gtk_window_get_position() and gtk_accelerator_parse().
Bug 644353, patch by Ulrik Sverdrup.
Backport annotations from master (which fixes the keyval_name() crash due to
the wrong default transfer annotation), and ensure that the g-ir-scanner
includes them.
https://launchnpad.net/bugs/732484
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.
Previously we were copying from the toplevel window unconditionally.
This is wrong in two cases:
1) composited windows
2) different visuals
So when encountering such a window in the hierarchy, we stop going up
and just use the latest window as the source.
https://bugzilla.gnome.org/show_bug.cgi?id=643416
Since GDK-Pixbuf is now in a package of its own, stop the distribution
of GDK-Pixbuf projects (those files are no longer referenced in the
GTK+ solution file already)
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
(cherry picked from commit 0b0f110152)
Conflicts:
gdk/x11/gdkscreen-x11.c
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.
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).
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.
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.
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.
When converting to gtk3, replace GtkComboBoxEntry with GtkComboxBox
has-entry=True, and remove the has-separator property from GtkDialogs.
Bug #639327.
With the recent deprecations going on, a lot of code doesn't compile
without warnings anymore. And instead of fixing maintenance-only code,
it's easier to just keep calling deprecated functions.
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.
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.
Bring back the note about using this with GtkComboBoxEntry because
otherwise it is a change of behaviour in the stable branch. This does
apparently still work because the get_active_text vfunc is implemented
in GtkComboBoxEntry.
Also make the deprecation note more helpful, giving a hint about what
to do in both cases. Note that the advice is ugly for the
GtkComboBoxEntry case and I wish there was real API for that.
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?
-Removed installation of gdkprivate.h and gtkprivate.h
-purge GDK-Pixbuf compilation stuff and added it as a dependency
-install demo program and demo sources and data in bin\gtk-demo
-made up for missing headers
Previously we used the size of the csw window, which could easily be
huge and cause CAIRO_SURFACE_INVALID_SIZE errors. If we use the real
size, we work around this problem. The surface can now potentially be
bigger than before but we should handle that when clipping in csw.
https://bugzilla.gnome.org/show_bug.cgi?id=633701
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)
The recently-used.xbel file location has been moved from $HOME to
$XDG_DATA_DIR, to be compliant with the desktop bookmark specification
and with other desktop environments following it.
The effective change was done in gtk+-3, but we need a migration path
for gtk+-2.
The possible cases are:
• the old file is not present, so we just switch to the new one;
• the old file is present, but the new one is not; in this case
we rename the old file to the new one.
• both the old file and the new file are present; in this case,
we try a simple merge of the contents and remove the old file.
The merge is the (obviously) more expensive option, but it should only
happen once.
https://bugzilla.gnome.org/show_bug.cgi?id=633242
Switch all usage of device color spaces to generic color spaces. Since
the former color spaces are no longer device-dependent as of Mac OS X
10.4, these yielded a very costly color space conversion when drawing
pixmaps to the screen. We now avoid this by using the generic color
space.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=624025
If the data that backs a bitmap context changes, then the CGImage that
is backed by this data might not always update due to caching effects.
By creating the CGImage on-demand, we ascertain ourselves that the
CGImage is up to date.
The gdk_drawable_ accessors were deprecated. Removes a lot of
compile-time warnings and eventually also makes things work again
on Mac (miscompile due to the missing prototypes).
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.
(cherry picked from commit 95e69afea8)
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.
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>
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.
(cherry picked from commit 9612c64817)
If you type 'subfolder/' and hit Enter, the file chooser will switch you to
it. But if you type just 'subfolder' without the trailing slash, apps would
receive *that* filename (e.g. file:///foo/bar/subfolder) as the response, and
they would likely print an error that they can't open that file (as it is
a folder). So, we change the file chooser's current folder to that subfolder
in this case.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Previously name_entry_get_parent_info_cb() would fail as it doesn't handle SELECT_FOLDER.
Now we just make that function act the same as for CREATE_FOLDER mode. In either
case, if you type "/blah/nonexistent" and hit Enter, you want a folder
with that name to be created (under the already-existing /blah).
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The old save_entry_get_info_cb() was misnamed; it is actually used
to see if a file's presumed parent *is* a folder. So we rename
it to name_entry_get_parent_info_cb().
Signed-off-by: Federico Mena Quintero <federico@novell.com>
file_exists_get_info_cb() used to let some actions fall through to
the code that checks for the file type of the selected file's parent
(e.g. to see if /foo/bar *is* indeed a folder if you type /foo/bar/baz).
However, we need to be more explicit for each file chooser action, as
in SELECT_FOLDER mode typing /foo/foldername and hitting Enter would not
give you an immediate selection, but rather the file chooser would
complain that it couldn't create that directory as it already exists.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
This commit adds
gdk_window_get_display
gdk_window_get_screen
gdk_window_get_visual
gdk_window_get_width
gdk_window_get_height
and deprecates the corresponding GdkDrawable APIs.
This will make it easier to prepare the port to GTK+ 3
This commit deprecates gtk_link_button_set_uri_hook(),
gtk_about_dialog_set_email_hook() and gtk_about_dialog_set_url_hook(),
and adds a GtkAboutDialog::activate-link signal.
gtk_notebook_set_window_creation_hook has been removed in GTK+ 3,
deprecate it here. gtk_notebook_get/set_group has been deprecated
in favour of the new gtk_notebook_get/set_group_name.
http://bugzilla.gnome.org/show_bug.cgi?id=630521
Since the location button is hidden in save mode, we need to add the
path bar to the size group too. The location button still has to be in
the group though, because it's larger than the path bar (when
shown). Instead of using the recent/search icons, add their hboxes so
that themed widget spacings don't introduce variations.
Add the composite overlay window to the cache, as this can be a reasonable Xdnd proxy as well.
This is only done when the screen is composited in order to avoid mapping
the COW. We assume that the CM is using the COW (which is true for pretty
much any CM currently in use).
https://bugzilla.gnome.org/show_bug.cgi?id=601731
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names. In GTK2, this header is included by default.
https://bugzilla.gnome.org/show_bug.cgi?id=629093
Add an ugly workaround because GTK does not ensure surfaces get flushed
before directly accessing the drawable backed by the surface. This is
not visible on X11 (where flushing is a no-op), but can be seen on
Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=628291
The attributes struct has some members that aren't covered by the
attributes_mask so they should always be filled in. The Win32 backend
was using the window type member when creating the window
implementation. Previously this was left uninitialized so it would end
up thinking the window is input_only and nothing would get painted.
https://bugzilla.gnome.org/show_bug.cgi?id=628049
Signed-off-by: Hans Breuer <hans@breuer.org>
Bug 628656 - _gdk_windowing_get_startup_notify_id memory leak
get_display_name() returns a newly allocated string, which was being fed
directory info a g_strdup_printf() call.
(cherry picked from commit bf3b5f785e)
TrackMouseEvent is present in user32.dll in all Windows versions we
support. No need to look it up dynamically. No need to fallback to
_TrackMouseEvent from comctrl32.dll.
Rename the orientation property to item-orientation, since that is
closer to the meaning of the property and avoids confusion with
GtkOrientable::orientation. Also add getter and setter for the new
property, and deprecate the old property and getter/setter.
The following style properties are there to let theme engines 'opt-in'
to more correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct behaviour,
and these properties will no longer be there in GTK+ 3:
GtkEntry::state-hint
GtkTreeView::row-ending-details
GtkRange::trough-side-details
GtkRange::stepper-position-details
GtkRange::activate-slider
When GDK looks for the window under pointer, the gdk-directfb backend
looks at windows starting from the root window to the upper window in
the stack. For this, it looks at window's size and position. This
patch fix the assumption that windows are always natives windows from
which we can retrieve backend's private data.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Since GDK has introduced the offscreen window concept, pixmap can be
created using drawables which aren't native windows. This patch fix
this assumption.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
The window management code used to deal with gdk internals. It seems a
lot of code has been pushed to the generic gdk code, so we remove
useless code.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Make it look more like the x11 backend. Also some people reported
crash early in the backend initialization about some colormap stuff,
this should avoid the problem.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
The event translation code used to deal a lot with gdk internals. It
seems a lot of code has been pushed to the generic gdk code, so we
needed to rewrite the things a little bit.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
The computation of abs_x,abs_y is done by the generic code of GDK when
events are raised. We don't care about that anymore.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
At least where standard names are available, instead of relying
on a symlink forest in the icon theme directory. For directional
variants, we look up icons by the pair ("foo-rtl", "foo") or
("foo-ltr", "foo"). See bug 626474.
- attributes->wclass is not consistently set anymore,
use private->input_only instead [1]
- don't put window into parent->children a second time
(now there is no window reference problem anymore)
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>
When a file was inserted during the period that the editable row was
active, the node IDs would not get updated correctly.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
This is an adapted version of commit
bde0f9a8f6 on master.
Mainly fixes to properly differentiate bewteen toplevel and offscreen
windows, since these sometimes need different treatment. Furthermore,
usage of gdk_window_get_effective_foo() instead of gdk_window_get_foo()
where applicable.
There is an drawing issue left when scrolling e.g. tree views in
offscreen windows. I think this is likely an issue with
gdk_quartz_draw_drawable() which is used for the copy area code in
offscreen windows. It works fine in master, since this was converted
to Cairo.
They were added as accessors for 2.22 even though querying the
background wasn't possible previously. As GTK 3.0 will change background
handling, it doesn't make sense at all to expose these getters.
[cherry-picked cd00b0a from master]
* Makefile.decl: make sure that check-local does not depend on a
recursive target for the tests. This way check can recurse and call
check-local in each folder which then invokes test-cwd. This will
make sure that a toplevel check-local doesn't recurse into subfolders
as well. The was resulting in test being run twice (for "/tests"), tree
times (e.g. for "/gtk/tests") and potentially more often
The previous version of the docs did not make it clear that has-window
is the defaults. Pointed out by Magnus Hjorth, bug 615474.
(cherry picked from commit 61e34032ec)
Gail did set the role to ATK_ROLE_TABLE for anything that is
not a GtkTreeStore. The propery way to do this is to look at the
tree model flags for list-onlyness. Bug 580291.
(cherry picked from commit 2686af2fbb)
These functions will be gone in Gtk 3.0 and be replaced by Cairo
functions.
Includes not disabling deprecated functions in old widgets that aren't
going to be ported.
This includes the addition of a "small" helper function,
_gtk_pango_fill_layout() that ignores color information. This
functionality is not available inside Pango and until that happens, we
need this fix. The bug is filed at:
https://bugzilla.gnome.org/show_bug.cgi?id=624917
49a0ec6e95 added this hunk without
explanations and it's obviously wrong because failing to have a get_size
vfunc will now not set width and height and they'll end up with invalid
values.
In fact, the GdkDrawableImpl{X11,Win32,Quartz} functions do not have
get_size implemented, so the patch was most likely an attempt to work
around calling this function erroneously on the impl objects.
The correct fix is to call impl->wrapper instead.
If gtk_drag_begin() gets passed GDK_CURRENT_TIME, try to use
gtk_get_current_event_time(). If it fails, use GDK_CURRENT_TIME when
ungrabbing in gtk_drag_end().
For more see https://bugzilla.gnome.org/show_bug.cgi?id=623865
The :limit property of GtkRecentManager does not serve any useful
purpose: the length of the list should be managed by the view
(implementing GtkRecentChooser), and not by the model (the recent
manager).
https://bugzilla.gnome.org/show_bug.cgi?id=624333
* gtk_tree_model_iter_next - 'inout' is poorly defined and causes bugs so
revert back to the default 'in' annotation
* gtk_tree_path_get_indices_with_depth - annotate the return as 'transfer none'
to avoid double frees
(cherry picked from commit b5f878dec8)
Previously we required an explicit "make html" in this subdirectory
for no reason. Just build it if make is invoked at the toplevel
and we have docbook.
As usual, this is protected by a style property:
GtkRange::stepper-position-details
The detail strings are
<detail>_start, <detail>_end and <detail>_middle.
See bug 621250
(cherry picked from commit e73a2e5654)
CUPS backend shouldn't handle "connecting-to-device" state reason.
It shows "Printer '%s' may not be connected" for this state,
which is not true in almost all cases. Better is to use
"printer-state-message" which contains correct message (#622011).
(cherry picked from commit 998459afb7)
Certain functions for GtkCalendar always return the same value. Therefore
they do not actually need to return a value at all.
Bug #621136.
(cherry picked from commit e19c50b538)
Previously we required an explicit "make html" in this subdirectory
for no reason. Just build it if make is invoked at the toplevel
and we have docbook.
WM_KILLFOCUS means that a keyboard grab (not a pointer grab), if any,
has been broken. I don't think this bug has matterd much as gtk
generates a grab-broken-event signal for both keybord and pointer
grabs being broken anyway.
The navigation region that got created for right-facing submenus when
moving the cursor up would have two negative values which caused the
check to go wrong.
I refactored the code to make that check into a separate function as it
makes the check not only harder to get wrong, but also the code easier
to read.
http://bugzilla.gnome.org/show_bug.cgi?id=620863
Add (transfer none) to the return value of gtk_text_buffer_create_mark(),
as the documentation clearly states the caller doesn't have ownership of
the returned value.
get_ellipsize_mode(), get_text_alignment(), get_text_orientation()
and get_text_size_group() were added in GTK+ 2.20, not 2.14.
Reported by Stanislas Marquis on IRC.
- Add gtk_assistant_commit()
This function discards the visited pages list so the back button is not
shown on the current page, and removes the cancel button from subsequent
pages. Use this when information provided thus far cannot be revisited.
- Don't show the Forward button on a GTK_ASSISTANT_PAGE_PROGRESS if it's
the last page (according to the forward page function).
- Append a progress page to the GtkAssistant demo.
In debian/ubuntu, builddir != srcdir. This trigger an error on
introspection_files where srcdir is added to x11/*.c. Indeed,
srcdir is added again later: $(addprefix $(srcdir)/,$(introspection_files))
making $(srcdir)/$(srcdir)/x11/*.c (not an issue on jhbuild as srcdir = .)
We now exit early from gdk_window_register_dnd() to avoid crashing if the
window type is GDK_WINDOW_OFFSCREEN and does not support dnd operations.
This makes it possible to use any dnd-enabled widgets, such as GtkEntry,
within a GtkOffscreenWindow.
Use ::keynav-failed for arrow navigation in icon views, so that
it is possible to override error handling. Also add API to get the
row/col of an item. With this, it is possible to make arrow keynav
span adjacent icon views, which is desired in the new control-center
shell. testiconview-keynav demonstrates this.
Changed the way to find the drop widget from a top->bottom recursion
using GdkWindow positions to a liner bottom->top walk up the widget
hierarchy using _gtk_widget_find_at_coords() and
gtk_widget_translate_coordinates(), which both do the right things for
offscreen widgets.
* gtk_tree_model_get_column_type: transfer none added to the return value
* gtk_tree_model_get_path: value parameter switched from inout to out
so that it is annotated with caller-allocates
Turn find_widget_under_pointer() into internal API
_gtk_widget_find_at_coords() which is needed for fixing above
bug. This should actually be a public utility function, and will be
moved to another file when its final API has been decided.
This reverts commit 5616bdc3dc.
I always thought cairo_region_t was a Cairo 1.8 feature. Apparently it
isn't, so the 3 patches I just reverted made Gtk depend on an unreleased
Cairo version. This is obviously not a good thing.
Expect those patches to reland once there's a Cairo 1.10 out (probably
around Gtk 4...)
Reading of PPD files collides with getting list of printers.
It helps to give higher priority to getting of PPDs than to
getting list of printers (#614581).
Includes fixing all callers to use the cairo region API instead. This is
usually just replacing the function names, the only difference is
gdk_region_get_rectangles() being replaced by
cairo_region_num_rectangles() and cairo_region_get_rectangle() which
required a bit more work.
https://bugzilla.gnome.org/show_bug.cgi?id=613284
This completes the move to get rid of using a GdkRegion for the
navigation region and the only user of gdk_region_polygon(). We keep
track of the triangle and compute in/out points ourselves now.
Unfortunately the DRAW_STAYUP_TRIANGLES debugging code doesn't work
using cairo, so I removed it completely.
* gtk/gtkrange.c: (gtk_range_adjustment_value_change):
Queue the draw also if the range is a scale and the value is drawn,
fixing bug #533946 (Markus Brinkmann), when two HScales use one
adjustment.
Also, added api to allow an input method to internally handle
key press and release events in the GtkTextView and GtkEntry
cases.
This is simply a wrapper to the gtk_im_context_filter_keypress()
function, but It's added to not access the ->im_context
directly.
Based on a Christian Dywan patch
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=163251
libstatic-pixbufloader-gdip-png.la should not be built or at least not
included in STATIC_GDIPLUS_LIBS as we don't want to use the GDI+-based
loader for PNG, because if we do, we can't get (or was it set?) the
options of a PNG pixbuf that for instance some code in GIMP wants to do.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=607839
The file removal code was not properly clearing the file=>array index
cache, so later lookups into that cache would return invalid array
indexes.
The easiest way to reproduce it is to create a directory with two files
and deleting both of them.
Reported-by: Javier Jardón <jjardon@gnome.org>
2010-05-02 14:36:53 +02:00
1693 changed files with 222476 additions and 258025 deletions
# YourProject_HEADERS_EXCLUDES = ... # <list of headers to exclude from installation, separated by '|', wildcards allowed; use random unsed value if none>
#
# dist-hook: \ # (or add to it if it is already there, note the vs9 items will also call the vs10 items in the process)
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.
Matthias Clasen
Chun-wei Fan
Chun-wei Fan
John Ralls
Ting-Wei Lan
Emmanuele Bassi
Philip Zander
Nam Nguyen
Alex Samorukov
Ming Hua
Emmanuele Bassi
Petr Viktorin
John Lindgren
Руслан Ижбулатов
Samuel Thibault
Marco Trevisan (Treviño)
Christoph Reiter
Eduard Braun
Brady Minardi
Daniel Boles
Benjamin Otte
Simon McVittie
Dominique Leuenberger
Dennis Schridde
Jeremy Tan
Ivan Zakharyaschev
Rafal Luzynski
Chris Lamb
Colomban Wendling
Piotr Drąg
Daniel Boles
Ingo Brückl
Andika Triwidada
Jasper St. Pierre
Balázs Úr
Michael Schumacher
TingPing
Nelson Benítez León
James Clarke
Lauri Kasanen
Jouke Witteveen
Kristian Rietveld
Paul Davis
Federico Mena Quintero
Benjamin Otte
William Jon McCann
Timothy Arceri
Ken VanDine
Dariusz Gadomski
Fredy Paquet
Allin Cottrell
Theppitak Karoonboonyanan
Frederic Crozat
Ignacio Casal Quinteiro
Yevgen Muntyan
Hans Breuer
Kiyotaka NISHIBORI
Dave Airlie
David Lechner
Paolo Borelli
Tom Schoonjans
Cédric Valmary
Kylie McClain
Marek Kasik
John Lindgren
Colin Walters
Christophe Fergeau
Daniel Drake
Arnav Singh
Lars Uebernickel
Holin
Jehan
Sebastian Gerhardt
Michał Górny
Andreas Müller
Yosef Or Boczko
Kalev Lember
Marc-André Lureau
Michael Natterer
Mike Gorse
Pavel
William Jon McCann
Giovanni Campagna
Luis Menina
Carlos Garnacho
Cody Russell
Balázs Úr
Theppitak Karoonboonyanan
Behdad Esfahbod
Ek Kato
David King
Michael Hutchison
Aleksander Morgado
Daniel Sabo
Michael Hutchinson
Takuro Ashie
Marc-Antoine Perennou
Hib Eris
Valerio Messina
Hendrik Knackstedt
Wolfgang Stoeggl
Tilman Sauerbek
Michael Natterer
Rémi Cardona
Nik Kalach
Alexander Larsson
Carlos Garnacho
Alan McGovern
Cosimo Cecchi
Changwoo Ryu
William Hua
Sebastian Geiger
Emanuele Aina
Nuno Araujo
Jan Rękorajski
Kjartan Maraas
Marko Lindqvist
Camillo Lugaresi
Kazuki Iwamoto
Kristian Rietveld
Hendrik Knackstedt
Emmanuele Bassi
YunQiang Su
Funda Wang
Connor Behan
Christian Kellner
Dumitru Mișu Moldovan
Carlos Garcia Campos
Javier Jardón
Mikael Magnusson
Bastien Nocera
Dieter Verfaillie
Stefan Sauer
Benjamin Berg
Ryan Lortie
Florian Müllner
Antoine Jacoutot
Richard Hughes
Egon Elbre
Martin Renold
Morten Welinder
Jerome Lambourg
Arnaud Charlet
Alex Corrado
Peter Clifton
Kristian Rietveld
Steffen Gutmann
Ihar Hrachyshka
Tor Lillqvist
Micah Carrick
Andika Triwidada
Michal Suchanek
Mario Blättermann
Daniel Mustieles
Stéphane Maniaci
Juan Pablo Ugarte
Mike Gorse
Daniel Drake
Marc-André Lureau
Jesse van den Kieboom
Wouter Bolsterlee
Pavel Holejsovsky
Martin Pitt
Tristan Van Berkom
Sebastian Pölsterl
Gabor Kelemen
Martin Nordholts
Luca Ferretti
Johan Dahlin
Christian Persch
Tomeu Vizoso
John (J5) Palmieri
Alan Knowles
Bruce Cowan
Milan Bouchet-Valat
Adrian Johnson
Adel Gadllah
Murray Cumming
Alejandro Piñeiro
Carlos Garcia Campos
Martyn Russell
Federico Mena Quintero
Petr Kovar
Jürg Billeter
Christian Dywan
Takayuki KUSANO
Cody Russell
Christian Dywan
Stephen Shaw
Claudio Saavedra
Kenneth Nielsen
Sweta Kothari
Jonh Wendell
Inaki Larranaga Murgoitio
Aron Xu
Bakaoukas Nikolaos
Gheyret Kenji
Christian Kirbach
Sebastian Dröge
Michael Meeks
Duarte Loreto
Matej Urbančič
Daniel Nylander
Baurzhan Muftakhidinov
Neil Roberts
Khaled Hosny
Chao-Hsiung Liao
Claude Paroz
Philip Withnall
Jorge González
Matthew Barnes
Yaron Shahrabani
Fran Diéguez
Carl-Anton Ingmarsson
Ivar Smolin
Mattias Põldaru
Lionel Landwerlin
Fridrich Štrba
Martin Schlemmer
Szilárd Pfeiffer
Bruno Brouard
Sergey Orlov
Sven Herzberg
Hiroyuki Ikezoe
Sam Thursfield
John Stowers
Philip Withnall
Cody Russell
Stanislav Brabec
Xan Lopez
Mirsal Ennaime
Chris Kühl
Stanislas Marquis
Thomas Wood
Vincent Untz
Yaakov Selkowitz
Steve Frécinaux
Didier Roche
Garrett Regier
Jan Arne Petersen
Paul Davis