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>
GtkTextView is missing accessors for its sealed hadjustment
and vadjustment members.
This patch adds gtk_text_view_get_hadjustment() and
gtk_text_view_get_vadjustment() to GtkTextView
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=616053
Currently the only users of the GTK_HAS_FOCUS flag are setting it
before sending a focus change event. This is normally needed by
GtkWindow, but there are widgets that require controlling the focus
of widgets that are semantically their children even though they are
parented to another top-level. Case in point: the quick search entry
for GtkTreeView.
Over the years people have been hacking the focus change out of
gtkwindow.c and gtktreeview.c, thus leaking the direct access of the
GTK_HAS_FOCUS flag.
The simplest way to avoid that is to add a function that sends the
focus change event and controls the setting of the flag, thus removing
the need for external widgets to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=593671
Bug 615853 - BadMatch when pressing keyboard volume keys while pointer in
secondary X screen
_gdk_windowing_get_shape_for_mask() is using the default screen, not taking
into account that its GdkBitmap could have been created for a different one,
causing BadMatch errors.
which also works for offscreen windows and their embedder.
Also add gdk_window_get_effective_parent() and
gdk_window_get_effective_toplevel() which are offscreen aware.
It doesn't make sense to determine an index into an array, if
you are going to sort the array afterwards...pointed out in
bug 615128 by Florian Scandella.
Currently gdk_screen_get_primary_monitor just returns the first monitor,
in this case but both the panel and now gnome-shell use an additional
heuristic to prefer LVDS as primary if present.
Move this heuristic to gdk_screen_get_primary_monitor to avoid duplicating
it all over the place.
The fallback heuristic is also used when no primary output is set.
https://bugzilla.gnome.org/show_bug.cgi?id=614894
We should not unref the model here, it might not even exist anymore.
Instead check if it exists and only use it if it does.
The unref was leftover from a previous fix in
ba9f53397f.
Spotted by Matthias Clasen in
https://bugzilla.gnome.org/show_bug.cgi?id=614099
In certain cases the menu label of a notebook page will be reused after the
page was removed from the notebook, for instance when a page is dragged from
one notebook to another. For such cases make sure that the menu label isn't
destroyed as part of destroying the menu item it was in.
One needs to add an explicit dependency between the gir files and the
.la libtool wrapper as this dependency is not added automatically by
Makefile.introspection. Not adding these breaks parallel builds as make
does not wait for the .la to be generated before launching g-ir-scanner.
Tracker 0.8 series (and late 0.7.xx) introduces new API based on SPARQL
query language. The queries here use fulltext search, just like with
with previous tracker versions. Old tracker 0.6 support is still maintained.
Emit notify::label in GtkMenuItem also when label is changed through GtkAction.
Refactor GtkMenuItem and remove duplicated code for GtkLabel creation. Reset
the accel-widget back to the GtkMenuItem itself when there is no action related
to the GtkMenuItem anymore.
Add test for notify::label emmisions.
Fixes bug 612574 - GtkMenuItem does not emit notify::label when label is
changed through GtkAction.
New patch makes sure to update the display even when
the GtkEntry's buffer is set to NULL, it also breaks the
reference to the buffer in ->dispose() instead of ->finalize().
With this change, key events continue to go to an open menu even
when the pointer is moved over a non-selectable menuitem. The mnemonics
are shown and hidden accordingly.
Patch by Jeroen Hoek. See bug 557420 for a prolonged discussion.
Quick summary of the removed sequences:
<Multi_key> <asciicircum> <0>
Consistency. <Multi_key> <asciicircum> [1..9] gives the superscript digit,
legacy sequence for zero is inconsistent.
<Multi_key> <c> <o>
<Multi_key> <c> <O>
Consistency. <Multi_key> <c> [:letter:] already gives vowel plus caron, legacy
sequence for c is inconsistent.
<Multi_key> <comma> <e>
<Multi_key> <comma> <E>
Consistency. <Multi_key> <comma> [:letter:] is for letter with cedilla,
<Multi_key> <semicolon> [:letter:] is for letter with ogolek
<Multi_key> <C> <slash>
<Multi_key> <slash> <C>
Unintuitive. ¢ is visually a vertical bar through a lowercase c, not a slash
through an uppercase C. ₡ has no alternatives, whilst ¢ can be typed as
<Multi_key> <bar> <c>.
<Multi_key> <d> <minus>
đ can be input through <Multi_key> <minus> <d>. <Multi_key> <d> <minus> is used
for ₫.
<Multi_key> <equal> <L>
<Multi_key> <L> <equal>
Unintuitive. ₤ has two dashes, £ one; therefore L + = > ₤, and L + - = £.
<Multi_key> <exclam> <s>
<Multi_key> <exclam> <S>
Consistency. <Multi_key> <exclam> [:letter:] is used for letter with dot below.
§ can be input using <Multi_key> <o> <s>.
<Multi_key> <period> <period>
Might need an alternative for ˙, but … (upstream) has no alternative either.
<Multi_key> <underscore> <a>
<Multi_key> <underscore> <A>
<Multi_key> <underscore> <o>
<Multi_key> <underscore> <O>
Consistency. <Multi_key> <underscore> [:vowel:] gives vowel with macron for ȳ ū
ī ē too.
<Multi_key> <minus> <d>
<Multi_key> <minus> <D>
<Multi_key> <o> <e>
<Multi_key> <O> <E>
Redundant. In upstream as is.
Get gdkkeysyms.h from git, instead of the outdated copy from svn.
Get Unicode 5.2.0 data. Fix a few issues with missing keysyms in
keysyms.txt. Make the filtering of non-BMP keysyms work.
Copying to the clipboard is not a buffer mutation, so calling
gtk_text_buffer_begin_user_action() and _end_user_action() is only
confusing apps which connect to these signals in order to build undo
stacks or otherwise track buffer changes. Most likely, these apps
either didn't notice the bugus undo step or simply work around it.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
There are no side effect of setting these flags and we don't fire g_object
notifies also. Thus set/unset right away without costly check of current state.
It turns out that my attempt at handling Super, Hyper and Meta better
is causing problems, mostly because Alt and Meta are commonly colocated
in the modmap, and apps do a check for the Alt modifier regularly.
See e.g bug 607697.
When the foreign window already has a GdkWindow, we forget to take
an extra references, leading to crashes later on. Patch by
Karl Tomlinson, bug 607061.
Patch from bug #591186. It won't have any effect in this branch as the
whole XP-and-later theming code is broken and disabled, but when/if
that is fixed, then this patch should help.
On X11 we receive enter notify and motion notify events for a window
regardless of its focus state. On Mac OS X this is not the case. This
commit improves the semantics to overcome this difference. It improves
on my earlier patch that sent a motion notify event when a window became
main.
Instead of sending a motion notify when a window becomes main, we now
send one when a window becomes key, which comes closest to a window
getting focus in X11. This motion notify is needed because Mac OS X does
not send motion events when an application is inactive (none of its
windows have focus), these events are sent in X11. This dummy motion
notify event (with current coordinates of the mouse cursor) allows an
application to get its prelight and other state right when it gets focus
and thus user attention.
Another change is to send an enter notify event when updating the
tracking rectangle of a GdkQuartView and the mouse cursor is currently in
this rectangle. This rectangle is at least updated on window creation.
This enter notify event is important for the case where a new window
appears right below the mouse cursor. The window has to receive an enter
notify event for the subsequent events to be processed correctly. Mac
OS X does not send one in this case, so we generate it ourselves.
Both of these synthesized events have to go through
_gdk_windowing_got_event() for updating statekeeping, etc.
append_event() has a boolean flag now to make this convenient.
Add accessors for range->range_rect, range->slider_range,
range->slider_size_fixed and range->min_slider_size. Didn't add
properties for any of them because thir purpose is mostly to enable
proper subclassing.
This is exposed by overshooting in a HildonPannableArea. Leaking
a GtkTreeRowReference also means leaking the whole model, since
the GtkTreeModel reference count is increased for each row
reference.
Fixes bug #607770 - Leak in GtkTreeView with HildonPannableArea
If e.g. the right edge of the leftmost rectangle is near MIN_INT, and
the left edge of the rightmost rectangle is large then subtracting these
can lead to an integer overflow, making the resultant "width" falsely
positive, thus returning a very wide result instead of the expected
no-intersection result.
We avoid the overflow by not doing the subtraction unless we know the
result will be positive. There are still risks for overflow if x + width
or y + width is larger than MAXINT, but we won't ever overflow for valid
rects now.
This may fix#607687
We need to do this because otherwise the implicit button grab for this
(native) window will not deliver the button events not selected for
by this window. This is a problem because non-native child windows may
select using a wider event mask, and we can't emulate these events if we
don't get the native events.
Fixes bug #607508
When a cairo surface is requested for direct window access (i.e. not
when double-buffering) we can't really track when the actual drawing happens
as cairo drawing is not virtualized. This means we can't properly flush
any outstanding window moves or implicit paints.
This actually causes problems with e.g. abiword (bug #606009) where they
draw without double-buffering. If you press down it scrolls the window
and then draws the caret, but the caret drawing does not flush the
outstanding move from the scroll, so the caret gets drawn on the wrong
screen.
We fix this by never allowing either implicit paints or outstanding window
moves on impl-windows where any windows related to it has an outstanding
direct cairo surface. Luckily this is not very common so in practice this
doesn't matter much.
* gtk/gtktoolpalette.[h|cc]: gtk_tool_palette_get_drop_group():
Change the return type from GtkWidget* to GtkToolItemGroup*,
for consistency with other parts of GTK+, such as GtkToolbar.
It may happen that a window gets destroyed during painting, if so
we should not draw the implicit paint double-buffered pixmap to it
as that will cause a BadDrawable X error.
This fixes bug 600865
Some link to GTK+ classes are not gererated because the ":" near
the class name; solution: "#GtkComboBox<!---->:"
Also, added some links to the proper signals
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=606291
Deprecate widget flag macros GTK_WIDGET_STATE, GTK_WIDGET_SAVED_STATE,
GTK_WIDGET_FLAGS, GTK_WIDGET_TOPLEVEL, GTK_WIDGET_NO_WINDOW and
GTK_WIDGET_COMPOSITE_CHILD.
Also deprecate the type macros GTK_WIDGET_TYPE, GTK_OBJECT_TYPE_NAME and
GTK_OBJECT_TYPE which have become redundant.
Instances of GTK_WIDGET_TOPLEVEL are replaced with gtk_widget_is_toplevel,
GTK_WIDGET_TYPE is replaced with G_OBJECT_TYPE, GTK_WIDGET_COMPOSITE_CHILD
is replaced with use of the "composite-child" property and uses of
GTK_WIDGET_NO_WINDOW are adjusted to use gtk_widget_get_has_window.
Uses of GTK_WIDGET_SAVED_STATE and GTK_WIDGET_FLAGS inside GtkWidget are
changed to direct flag usage.
Documentation is updated to refer to gtk_widget_set_has_window and
gtk_widget_get_has_window.
Gail and tests are updated as well.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=69872
These have been introduced in Leopard and default to int and unsigned int.
In 64-bit Snow Leopard they are long and unsigned long. This caused issues
with the getRectsBeingDrawn message which needs a pointer to a NSInteger
(long on 64-bit!) but we passed in an integer. Surprisingly this problem
was visible when compiling with -O0 (segfault), but *not* when compiling
with -O1. Other messages were NSInteger is now needed have also been
adapted.
Since NSInteger and NSUInteger are not available on Tiger, a define
has been added to add typedefs for these when they have not been defined
by the system headers.
Initialize event_last_[xy] to out of range coordinates and also update
these values in enter and leave notify. Fix up calls to
update_prelight() from size allocate. Unconditionally doing these calls
caused problems with hover selection. Now we only do this call when
the "width before the expander column" has changed. (Which might be
awkward, but it is the best heuristic I could come up with so far).
Commit again after revert.
Store (x, y) of last motion event. From
gtk_tree_view_adjustment_changed(), call prelight_or_select() so that
the prelight is recalculated. We do the same from
gtk_tree_view_size_allocate() for the case that clicking on an expander
shows new rows that resize the column(s) left of the expander. This
means that the expander is moved horizontally, in such a case the
prelight also has to be reconsidered.
This patch changes GDK to add all matching virtual modifiers in
the state field of the key event. The corresponding GTK+ change makes
use of a new GdkKeymap function to map virtual modifiers back to
real modifiers and detect conflicts while doing so.
This should fix bug 603190 and bug 427409.
...and show them in menus when navigating the menu with the keyboard.
This is similar to what other platforms do, and reduces visual clutter.
There is a setting to control this. Most of the work on this patch was
done by Thomas Wood. See bug 588554.
This adds LDFLAGS everywhere where they were previously pulled in via
other libraries. This is however unsupported by modern linkers.
You can trigger these failures by building with gold (or, I'm told, with
very new ld).
Not removing the signal handler caused crashes if the adjustment
survived longer than the scrolled window and still emitted signals. This
could happen inside WebKit.
GtkIconSize is an extensible enumeration (via
gtk_icon_size_register()), so methods that claim to take/return a
GtkIconSize need to actually use "int" to work correctly with bindings
that are strict about enum values.
https://bugzilla.gnome.org/show_bug.cgi?id=604895
This patch adds an icc-profile option to a GdkPixbuf which can
be used to read or write an embedded ICC profile.
Add PNG support for now, but other image formats are awaiting
review.
The Gtk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GTK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
The Gdk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GDK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
https://bugzilla.gnome.org/show_bug.cgi?id=592279
Intermediate commit of work in progress on integrating the old code
for OLE2-based generic drag and drop from Arhaeopteryx Software, from
a long time ago in the GTK+ 1.3 timeframe. Does still not work and is
as before not compiled in unless OLE2_DND is defined in
gdkdnd-win32.c. (Thus, for inter-process DND, still only WM_DROPFILES
style dropping of files on GTK+ apps works.)
Related slight refactoring of other code that shouldn't change how it
works. Add more global variables for run-time constants (once
initialized) representing well-known GdkAtoms and registered Windows
clipboard formats, as they with the generic DND code will be needed in
several source files. Some improved debugging output.
Add a couple type checks in gtk_activatable_do_set_related_action() to
allow both GtkWidgets and GtkActions to implement GtkActivatable. Bug
602099 describes a use case for this.
Also add a GObject prerequisite to the GtkActivatable interface.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=604289
In order to respect this properly, we have to restore the original
behavior by watching a flag to check if the user has already set this.
* gtk/gtkassistant.c: fix the bug by introducing a flag to check for
non-automatic value setting
* tests/testassistant.c: updated the "generous assistant" to permit
quick manual testing of this feature
They don't need double buffer combination since they have no
client-side children, and creating pixmaps for them is risky
since they could disappear at any time.
May fix bug 598476 and 603652.
It may happen when turning a client side window into a native window
that the window, or some of its children with the same native parent
have extension events enabled, and thus have an input window enabled
for the native parent which needs to change as the window is made
native.
We fix this by temporarily disabling extension events on all the affected
windows while we create the native window, and then reenable them afterwards.
This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=544624
All kinds of lines (lines, segments, arcs, etc) need to take into
account the line properties (width, miter limit, joins, caps, etc)
to get proper damage extents.
This is not really possible to do, but we can make it likely to work
with some ad-hoc estimates.
Fixes bug 603904.
The fix in 786b589d95 for the
"Cannot click buttons more than once without moving the mouse cursor"
did not correctly handle setups with multiple screens in one display.
We need to handle the case where the first XQueryPointer returns
a different root window than the default one.
This fixes bug 597386 (agaion)
GtkCellEditable::editing-canceled property was added in 2.19 cycle,
so we should make the code that currently uses entry->editing_canceled
directly go through the property
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=599213
We don't really need to filter these out, it was just a leftover
safety check to not override the GDK_POINTER_MOTION_MASK.
Furthermore when we changed behaviour to not always select for native
pointer motion it is actually wrong. We'll still get normal motion
events for the toplevel which we will emulate as button motion on the
child, but the button motion mask will not be inherited by implicit
grabs which makes us not get any motion events during grabs.
This fixes bug 601473
This enables applications to read out the compression of a TIFF image
and also makes it possible to apply the same or a different
compression when saving.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=584700
If you add a new ui node that was recently removed it will still be
in the tree, but marked dirty. In this case we previously just used
the old node, which meant it wouldn't get the same position as if
the dirty nodes had been processed first (and deleted) before the
new node was added.
We handle this by detecting this case and reposition the node as if
it was new.
https://bugzilla.gnome.org/show_bug.cgi?id=603128
So they're not included in the result of gtk_container_foreach() which
preserves it as a convenient way to get the list of all notebook content
widgets.
Bug #601409.
Although it isnt' allowed by the XEMBED protocol, its possible
that the plug window will be reparented out of the socket without
the socket having done so. See bug 123569. Patch by David Jander.
Add always-show-image="true|false" attribute to <menuitem> element in UI
manager markup. If present, it overrides the always-show-image property
on image menu items. Bug #589842.
Rework double click handling in GtkTreeView. We cannot blindly use
the 2BUTTON_PRESS and 3BUTTON_PRESS events. In case a user does two
fast double clicks, we receive a 3BUTTON_PRESS and BUTTON_PRESS. We
cannot easily deduce two double clicks from this.
We have removed the bookkeeping using row references of the last paths
clicked. Instead we monitor event time, (x, y) coordinates and compare
against double-click-time and double-click-distance ourselves.
Store (x, y) of last motion event. From
gtk_tree_view_adjustment_changed(), call prelight_or_select() so that
the prelight is recalculated. We do the same from
gtk_tree_view_size_allocate() for the case that clicking on an expander
shows new rows that resize the column(s) left of the expander. This
means that the expander is moved horizontally, in such a case the
prelight also has to be reconsidered.
This should now cause much less of a headache than before. Fields have
been properly reordered, each group has been given a comment. Since the
GtkTreePrivate structure is private (as the name says), this should not
have any effect on ABI.
gtk_tree_model_filter_set_visible_func() is checking for
priv->visible_func, but that is always going to be NULL since there's
no way to call this function twice.
Besides that the code itself is wrong, since it tries to call
priv->visible_destroy without making sure that it's not NULL
Bypassed with #if 0 because it is an awful hack and not really
acceptable from a privacy point of view for instance. It prevents
Firefox from deleting temporary files containing images being dragged,
so they stay on disk. Bug #561973.
GdkNativeWindow cast is needed in 64-bit Windows so gpointer data
is converted to a (64-bit) native window handle.
GPOINTER_TO_UINT() is used in other platforms.
GPOINTER_TO_UINT() *does* drop the upper 32 bits on 64-bit
Windows. After all, it by definition produces a (32-bit) unsigned int.
The GLib commit mentioned in the reverted commit's log message just
means that it does this without any compiler warning about casting
from pointer to integer of smaller size, as it first casts to a 64-bit
integer, then casts that to a (32-bit) int.
We must use the GdkNativeWindow cast here so that on 64-bit Windows
the gpointer data in embedded_list is converted to a (64-bit) native
window handle without going through 32-bit truncation. If ifdefs are
required to avoid compiler warnings on X11, so be it then. Probably it
would be best to introduce a GDK_GPOINTER_TO_NATIVE_WINDOW() macro in
gdktypes.h.
This reverts commit 78151dc7d4.
Add support for putting widgets in the tab area, before or after
the tabs. This was requested a long time ago in bug 116650. The
implementation is the work of Johannes Schmid.
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600158
When we just invalidate some area from the app we don't need to clear
windows with no exposure mask, because that wouldn't have happened pre-csw
anyway. Additionally we can avoid such clearing for native windows in cases
where the xserver already did the clearing like on exposes or when resizing
toplevels.
This means we don't fully redraw a GtkSocket when it resizes, thus
avoiding flicker in gnome-mplayer as reported in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=598050
Backends that support native window background setting (and that clears
new window areas to this color/pixmap) should set this to true.
Currently only X11 supports this.
When moving or scrolling a window with native children, there is no
need to expose the areas that are copied by the windowing system
as part of moving/resizing the native windows anyway.
Just use the C library instead to create the file. Helps building
using Wine. Not that I think we want to endorse that way to build GTK+
for Windows, proper cross-compiling surely probably more sense, but
accepting this minimal patch doesn't hurt. From bug #590017.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
This allows disposing of the filesystemmodel while the file enumeration
is still happening.
As the filechooser does not disconnect its signals because it assumes it
is the only owner of the model, this also prevents a SEGV when emitting
the "load-finished" signal in that case.
Fixed the prototypes of MyEnhancedXkbTranslateKeyCode() and
translate_keysym() to take a gint* because those functions treat
these arguments as an int, so we get around the need to cast.
The translation_domain argument should be const gchar * to allow compilation
with -Wwrite-strings. It only passes the argument to
g_option_context_add_main_entries() which is already const gchar*.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=583305
We have to do this, especially after the screen containing the menubar
has changed. Such more larger changes in monitor geometry will cause
changes to how monitors are laid out in the root window. The position
coordinates of the windows will have to be updated to reflect their
position in the new layout.
The Quartz port now supports arbitrary multiple monitor layouts instead
of only monitors are were laid out horizontally. This builds on the
reworked coordinate translation done in a previous commit.
The root window contains all the monitors attached to a Mac. The
coordinate transformation now both translates the x and y coordinate,
translating it from the Cocoa monitor coordinate space to the GDK
coordinate space. How monitors are laid out in the root window differs
between Cocoa and GDK, which is why it is important to translate based
on the root window to get multi monitor setups to work properly.
We have replaced the old y coordinate transformation function with
new functions that translate both the x and y coordinate.
When creating new toplevels, we have to determine the Cocoa screen on
which the toplevel should appear and translate the coordinates according
to that screen.
This change also fixes event handling in case there is a monitor left
of the screen containing the menu bar. In such a case all coordinates
on the left monitor are negative. Event handling broke, because of
_gdk_quartz_window_find_child() checking bounds. Now that coordinates
are always properly translated to GDK coordinate space, in which negative
coordinates do never occur, the checks here will work properly.
Using this we can update our internal monitor/screen layout state
and emit the GdkScreen::size-changed signal. Work has not
completely finished on this yet, see bug 596238.
Run gtk_icon_view_layout() if necessary before attempting to paint the
icon view items during an expose event. This ensures all the items have
valid sizes, as some themes don't take kindly to negative dimensions.
Add dummy for _gdk_input_window_crossing (). Set both input_window_destroy
and input_window_crossing pointers in the Impl struct.
Reported by John Ralls.
Previously the filename would get re-set on the button if one cleared the selection,
as an async cancellable was not getting canceled in that case.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
GTK_ENTRY()->editing_canceled should really have been a parameter of the
GtkCellEditable::editing-done signal, it should be a property on the cell
editable interface
https://bugzilla.gnome.org/show_bug.cgi?id=594962
Although, you can use:
gtk_widget_get_parent_window (gtk_bin_get_child (GTK_BIN (widget)))
there already are gtk_tree_view_get_bin_window() and
gtk_layout_get_bin_window() in GTK+ api.
https://bugzilla.gnome.org/show_bug.cgi?id=594960
The root window width and height have already been correctly
initialised in _gdk_root_window_size_init() to cover all monitors, so
don't incorrectly re-initialise using GetSystemMetrics(SM_C[XY]SCREEN)
which only gives the size of the primary monitor anyway. (See MSDN.)
This fixes at least gdk_screen_get_{width,height}() which indirectly
affects at least the positioning of combo box pop-up menus on multiple
monitors.
When GtkMisc padding is set on an image, the optimization for only
recalculating size after a clear() breaks, since the requisition is
not (0, 0). We need a separate 'need_calc' flag.
Every call to _gtk_file_system_model_new*() gets the same list of column types,
so we now keep the list in a macro instead of having duplicated copies all around.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The old semantics was to return a GFile* owned by the file system model; the new
semantics is to hand out new references whenever possible.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
There was some confusion between "index" as used for the model->files[] array,
and node->index as used for our 1-based row numbers. Now we use "index" only
for indices in the model->files[] array, and node->row for row numbers. Functions
and variables are renamed to clarify whether they refer to indexes or rows.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The non-standard "filechooser::mime-type" was a remnant of the recent-files code using
a hand-built GFileInfo; now we just query the file info ourselves.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
g_array_new() doesn't reserve any size by default, so during the initial population
of the file array, we'll do more reallocs than strictly needed. We'll start with
a reasonable preallocated size, in this case the number of files which we can
get in a single chunk out of GIO.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
There's no point in running a GtkFileSystemModel with invalid column types.
This way we can also avoid clearing the memory of the column_types array.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The previous function enumerated the whole directory and used a lot of
outdated API to decide how to show files.
The new code queries the filesystem model to decide about this.
The now unused old functions were removed.
Previously information about file sizes was not available for search
results and recent files, so the column was always hidden. As this
information is now available, we can stop the special handling and use
the same setting as in browse mode.
Use the faster _gtk_file_system_model_get_value() function instead of
gtk_tree_model_get() inside the sort functions. This gives a significant
speed-up when sorting large lists.
In a test case with 40.000 files, the sorting time went from ~5 seconds
to less than 0.5 seconds for my test case. There is 2 significant
problems with gtk_tree_model_get() that cause this:
1) The value is copied, which takes quite a bit of time for strings.
~25% of excessive time or ~1 second in my test
2) The tree model functions need to lookup the interface vfunc. And
gtk_tree_model_get() doesn't do that only once, but multiple times
(verifying column id, getting the actual value, ...)
~75% of excessive time or ~3 seconds in my test
Replace the list model code with the file system model and use all the
file system model API niceties we get from that.
Also adds the function _gtk_file_system_model_add_and_query_file() which
g_file_query_info()'s the file before adding it, so it gets added with
the right information.
Since the time taken by g_file_enumerate_children() depends a lot on the
attributes that are queried, we query the minimum attributes that need
to be queired to display the file chooser.
In particular, the attributes for loading the icon are ignored, as icons
are loaded on demand (see previous commit).
Because loading icons takes a noticable performance, this code loads the
pixbuf on demand and only loads icons for rows that are visible. There
is a few caveats to this:
- The pixbuf cell renderer must report the proer size even if the icon
is not yet loaded. This is achieved by setting a fixed size.
- On theme changes the cahced pixbufs and the cell renderer must be
updated to conform to the new theme.
Previously, there was a GtkTreeSortModel wrapped around the filesystem
model to make it sortable. As the new implementation implements the
GtkTreeSortable interface, we can use this instead.
A lot of code special cases accesses to the tree view for the different
browse modes, which was previously necessary, because the models were
different. Now that they are identical in the first columns, there is no
such need anymore, and the functions don't need to be special cased.
Previously custom functions were used to compute the data passed to the
cell renderers. Now that all this data is saved by the tree models with
compatible nodes, the usual default attribute-to-column mapping can be
used.
With this, caching of the values can happen in the tree model, which
avoids costly lookups of icons or computation of strings. Last but not
least it avoids spurious bugs that could happen when strings changed
without anyone noticing, like the mtime when a new day begins.
All tree models in browse mode now share the first 10 column types
containing all the necessary information to display the model on screen.
Therefor it is now easy to just operate on the tree model associated
with the file tree view and in most cases it isn't necessary anymore to
special case the browse modes.
The new model is mostly API-compatible with the old model (minimal
changes were required), but is a lot faster and has a lot of very
desirable features.
- the model does no longer support a tree, just a list of files in a
given directory
- the storage has been moved to a GArray as opposed to a tree
- no more dependency on GtkFileSystem
- columns are managed by the creator of the model, so any number of
nodes can be added as needed. This also makes the API more similar
to GtkListStore.
- Values are filled on demand using a function given when creating the
model.
- The function can decide to let the model cache returned values or
decide to be called again the next time the value is queried.
- implements GtkTreeSortable
- _gtk_file_system_model_get_value() was added to significantly speed
up value access, which is necessary when sorting large models.
Add API for GtkDialog to return widgets by response ID.
Added gtk_dialog_get_widget_for_response() to access to all kinds
of buttons with all kinds of responses.
Zero width/height is unsupported and will magically be turned into one.
For instance, gtk_widget_size_allocate() will eventually do this magic
on the value stored in widget->allocation.
However, if we don't do this magic conversion early, then the value
returned from gtk_window_compute_configure_request() will not be
comparable with whats stored in widget->allocation. (I.E. they will
differ if width or height are zero).
This is dangerous, as we do such a comparison in gtk_window_move_resize().
Currently a change from e.g. 10x1 (current allocation) to 10x0 (new size)
will be expected to produce a ConfigureNotify, when it actually won't,
thus never thawing the frozen toplevel.
Fixes bug #588059
We need to do a final XQueryWindow to get the coordinates inside the
windows rather than in the parent window.
This fixes bug #597386, "Cannot click buttons more than once...", which
failed due to the grab tracking stuff getting the wrong coordinates as
per the above.
Thanks gcc :
gdkwindow-x11.c:1731: warning: passing argument 3 of
'XReconfigureWMWindow' makes integer from pointer without a cast
/usr/include/X11/Xlib.h:1871: note: expected 'int' but argument is of
type 'struct GdkScreen *'
Signed-off-by: Pascal Terjan <pterjan@mandriva.com>
The convention for landscape pages, and required by PostScript
Language Reference Manual, is for landscape printing to rotate user
space 90 degrees counterclockwise. Part of bug 596423
Like the other GtkSettings already registered, these are influenced from
the outside and cannot be properly tested. The defaultvalues test
passes again now.
gtk_tree_model_build_level() always needs to emit row-inserted when
requested, this should not depend on whether the level has a parent
level or a virtual root, which is a check whether or not we need to
reference the node in the child model. Furthermore, we also need
to emit row-has-child-toggled after row-inserted when appropriate.
When gtk_tree_model_filter_row_changed() pulls in the root level, it
must request build_level() to emit signals for this. The refilter
function uses row_changed to process the changes, so build_level() in
the first call to row_changed() might pull in multiple new nodes in this
scenario, for all of these signals need to be emitted. Of course,
build_level() will then also emit the signals for the node row_changed()
is processing, we should not emit a duplicate signal, this is now
accounted for.
Add a unit test for this. For this small functionality to block the
row-changed signal has been implemented, so that we can simulate calls
to the refilter function using the current visible column setup.
_gtk_tooltip_handle_event, which is called for many events in the GTK+
main loop, calls gtk_tooltip_set_last_window, which keeps a weak
reference to the last window we passed through. If the window being
set is the same than the last one there's really no need to update our
weak reference, so add a check for that and exit early.
These event types propagate up the hierarchy anyway, so this means
we avoid setting it unnecessarily. This is especially important
for button press event, since only one client can select for this
on each window, causing X errors if two clients do it.
This detection code is not 100% reliable, but it should fare much better
than the current code, which just compares the device name to a fixed
set of strings. Many applications depend on erasers being recognized
reliably, so we start by checking for a device name containing the
substring 'eraser'.
Signed-off-by: Thomas Jaeger <ThJaeger@gmail.com>
This has two advantages:
1) In many backends, this is faster as we can terminate the window
hierarchy traversal earlier
2) When used in gdkdisplay.c::get_current_toplevel() to get the
current toplevel that has the pointer we now correctly return
a toplevel with the pointer in it where the pointer is inside
some foreign subwindow of a toplevel window.
The second advantage fixes some bugs in client side event generation
when the pointer is inside such a foreign child window.
Based on first patches by Christian Hergert. Change
screen_get_monitor_geometry() so that it translates the layout of the screens
from Cocoa layout to GDK layout. In Cocoa, the screen locations
are specified in Cocoa geometry, as well as that GDK uses a different way
to place individual monitors in the root window. For now only monitors
that are laid out horizontally are supported (see the FIXMEs in the source),
in bug 596238 we will track future work to get things fully right.
Modify _gdk_quartz_window_get_inverted_screen_y() to take the differences
in screen layout between Cocoa and GDK into account. Also this function
is subject to future work.
Explicitly handle resizing by leaving all events in the lower right 15x15
corner to Cocoa, if the window shows a resizing indicator. Some
applications may have widgets allocated in this area. Generally, these
widgets are likely larger than 15x15 so they can still be hit. Often
scroll bars are found in this area and these can also be manipulated by
other means. Since this is the only way of resizing windows on Mac OS X,
it is too important to keep it broken.
When we grab the pointer we need to request more events than what is
specified, otherwise our event emulation stop working and you won't
e.g. get crossing event unless you specified motion event mask.
F-Spot needs this as it draws on a foreign (screensaver) window, which
used to work.
I believe this is safe, because in all typical cases the expose
mask will not be set, so we won't do anything, and its what we used to
do.
Check for 'auth-info-required' attribute from printer attributes to
find out whether an authentization of user is needed.
Change password dialog of print backend to be able to require informations
requested thru 'auth-info-required' (#566522).
This patch tests availability of remote host before getting ppd file
for selected printer (#586207). It also adds a state message for
failure of getting details.
progress-border and invisible-char style properties had wrong amount
of colons for gtk-doc (signal markup instead of properties), so the
Since tags didn't seem to get picked up.
GtkEntry:invisible-char also had a wrong Since: 2.22, fixed to 2.18.
Make the quartz backend support the new queued translations. We do this
by keeping our own copy of the region that has been set to need display.
Using this region we can intersect by the given area, translate this and also
set needs display for the resulting area.
With Bug 302240, a check was added to avoid keynav to unrealized
radio buttons in the group, but that's not the right check - the
check should be on MAPPED instead, since a widget can be realized
even if it, or a parent, is hidden. Bug 595599
When filtering out the events for "window" from the events we got for
our "impl_window", don't forget to adjust the returned number of
events because it might be smaller than what XGetMotionEvents has
returned, and free coords we allocated too much. Also if we filtered
away *all* events, return FALSE and get rid of the allocated history
entirely. Together fixes all sorts of mishehavior when painting in
GIMP, from coords going wild to plain crashes and infinite loops.
When a SIGPIPE signal is raised during printing with lpr,
application should not be killed by the signal but a standard
error-workflow should be performed (bug #503776).
On startup, the root window got assigned the size of the main screen.
But, the GdkScreen has the width of all screens/monitors connected to the
machine. Change this so that in _gdk_windowing_window_init, we assign
the width/height of all monitors to the root window width, height.
Should fix bug 594738.
The quartz backend simulates the semantics of XGrabPointer, as a part of
this it checks the event mask of the grab. However, implicit grabs on X
do not go through XGrabPointer and thus the quartz backend should not check
the event mask for these. This fixes various "the UI got stuck" cases.
Applications using non-double-buffered drawing using cairo (e.g. Abiword)
can draw directly to the window using cairo and thus manage to avoid
the automatic flushing of outstanding moves. This can cause redraw
inconsistencies like bug 593507.
We fix this by always flushing when exposing non-double-buffered widgets.
If we move, resize or otherwise change a window from inside a (double
buffered) expose handler we can run into issues with double buffered
paints that have already been ended but have not yet been commited
to the window from the implicit paint pixmap.
For instance, any copies of source regions due to a window scroll need
to take these into account, and any operation that causes some drawing at
a destination covered by the implicit paint region would be overdrawn
when the implicit paint is ended.
So, before we do any window-hierarchy changing operation while an implicit
paint is in effect we flush all moves and already commited paints.
When a window is moved or resized from a double-buffered expose handler
we can't really just copy the window region around, as the window
will be overdrawn with the double buffered region when the expose returns.
Instead we remove all regions with outstanding implicit paints from the
region to be copied and just mark this area as invalid to be redrawn
later.
This fixes bug 594880.
Its not correct for recurse gdk_window_process_updates_internal, as
the outer instance will overdraw the inner. So, protect against
gdk_window_process_updates() being called while in an expose
handler.
This shouldn't be a repaint problem, as eventually the idle handler
will cause the updates to be processed.
Some recent versions of libtoolize output a version blurb like:
libtoolize (GNU libtool 1.3110 2009-07-01) 2.2.7a
Don't get confused by the numbers inside the parens.
We used to handle zero height/width specially in the non-double buffered
case due to the weird behaviour of XClearArea in this case. However
this is undocumented, incompatible with what happens on double-buffered
drawing, and just not a good API. So, we drop this behaviour, having
fixed gtkclist.c which used this.
There are two issues here. First of all an ignored update didn't
use to unset update_idle which could cause all further idle repaints
to be ignored. (Bug #591583)
Secondly, if we ignore the process_all_updates we may end up not updating
the windows in update_windows unless something else triggers an update.
So, we handle this by checking for recursions and scheduling a new update
at the end of the outermost process_all_updates.
Fixed the button-sensivity patch done to GtkComboBox to account for
changes in appearance (changes to the appears-as-list style property).
Also, in list-mode, the event box that has been created below the cell
view also needs to have its sensitivity updated.
Commit 3f306a4042 made it possible for
gtk_tree_view_top_row_to_dy() to be called recursively. (In a different
way than was already guarded for). This caused a single test case in
the scrolling test suite to fail. We now also guard for recursive calls at
the beginning of gtk_tree_view_top_row_to_dy().
Rework the sort and filter models to store their reference to the parent
element as an array index instead of a pointer to an array element.
These pointers could become invalid with any array modification, whereas
indices do not.
If we have a level with zero visible nodes and the first node becomes
visible in that level, then parent has just become a "real" parent node.
In such a case we need to emit row-has-child-toggled. This only applies
to non-root levels that have a parent. This problem was also found when
writing the unit test, the respective cases in the unit test have been
corrected.
This fixes bugs:
Bug 372010 - Filtering not working properly
Bug 525965 - Filtered and sorted GtkTreeView is missing rows
When a filter function is used that determines the visibility property
of a node using whether or it it has children, the state of this node
very likely changes when the filter model receives a
row-has-child-toggled signal. Therefore, we need to handle state
changes in the row-has-child-toggled handler.
The license field was introduced later on, so some out-of-tree loaders
may not set it. And Solaris printf() doesn't take NULL for a string...
Bug 594178.
Add a function to obtain the effective context id, and reset the slave
only when the effective context id is different from the current context
id, when setting a client window and on focus in. This might fix
bug 593868 and bug 567124.
Also use a different means to check that the given mark is in the text
view's buffer. This will also play nice with anonymous and NULL marks.
Suggested by Paolo Borelli.
When unsetting the old buffer always set the buffer on the layout to
NULL. More importantly, clear the pending scroll. (The scroll is
handled in an idle, when not cleared an idle handler might touch the
layout later on, possibly corrupting the BTree). Unref the buffer after
removing the selection from the clipboard, not before. Patch merged
from maemo-gtk.
In gtk_text_view_queue_scroll() we need to verify if the given mark
exists in the text view's current buffer. When not done, this can
result in corruption of the BTree data structure. Patch merged from
maemo-gtk.
Updating the IM spot location in gtk_text_view_value_changed() might
invalidate the layout, so we need to make sure that we update it before
validating the layout again. Otherwise, the layout will be invalidated
right after validating it (possibly resulting in a failed
onscreen_validated assertion). Patch merged from maemo-gtk.
Likewise to other cell renderers, GtkCellRendererToggle now properly
follows the insensitive state of the widget requesting rendering. It
does this by checking the state of the widget pointer, not by using
GtkCellRendererFlags (there exists an insensitive flags). Later on, I
think we should move to using GtkCellRendererFlags and not the state of
the widget requesting rendering. Patch merged from maemo-gtk.
If the cell view is insensitive, it needs to properly propagate this
insensitive state to the cell renderers using cell renderer flags.
Merged from maemo-gtk.
This was removed long ago by the patch in bug 101235. On a hindsight,
all other scrollable widgets are processing exposes at this point, which
completely makes sense to me, so I am putting it back.
The check for a possible implicit paint flush before queueing an
antiexposure was wrong. An implicit flush doesn't actually NULL
the implicit paint, se we have add a flag to explicitly track if
it is flushed.
Passing region into _gdk_gc_set_clip_region_internal takes ownership,
so don't use it after that. We can just as well just move the usage
above the call.
Generally you only need to work around bugs in one specific app, so we
don't want to affect the applications that application will start.
Thus we unset GDK_NATIVE_WINDOWS after reading it.
For toplevels, never apply clip as shape, instead apply shape.
This way we don't have to re-set it all the time as the window size
changes. Furthermore, this change fixes unsetting a shape on a
toplevel window which didn't actually unset the shape before.
Additionally we never apply clips as shape if the shape would just
be the same as the regular window size. This means we won't unnecessarily
add a useless shape to most native child windows (and additionally this
helps apps that do weird X stuff that don't expect these shaped windows).
I.e. we use:
impl_iface = GDK_WINDOW_IMPL_GET_IFACE (private->impl);
And then use impl_iface instead of the full macro when calling vfuncs.
Also, in some places we avoid getting the iface multiple times.
Change default values returned by gtk_print_settings_get_printer_lpi()
and gtk_print_settings_get_resolution{_x, _y}(). New values are 150 for
lpi and 300 for resolution (instead of 0) (#590861).
Special case \r\n in gtk_text_buffer_backspace since \r should not be
reinserted even if we are deleting one char at a time. Also add
corresponding unit test. Fixes bug #544724.
Such paths (eg. a child node that is collapsed) should be ignored. This
is fixed by checking the return value of _gtk_tree_view_find_node(),
which returns a partial return value (the parent node) when it returns
TRUE. Also added a unit test.
Reorder drawing in gtk_tree_view_bin_expose() so that the tree lines are
drawn after the cells have been drawn. This is because cell-background
is handled in the cell renderer, so the tree lines need to be drawn
after this.
Contrary to what was believed before, do_validate_rows() does need to
queue a normal resize (including a redraw) when it has to. The redraw
is required because of the size of the tree has changed because new
row(s) have been validated.
Block 2BUTTON and 3BUTTON press events using a button press event
handler in GtkCellRendererSpin, so that they won't be eaten and
processed by tree view.
Previously the rightmost button with a proper response id was activated,
this is now only done if there is no default button set.
With this patch the right widget gets activated when there are multiple
widgets wth response ids conforming to is_stock_accept_response_id() as
the selected widget is made the new default widget before showing the
overwrite confirmation dialog.
For instance, two clients selecting for button events can cause BadAccess.
This fixes bug 592624, where a gdk_window_reparent caused us to re-set
the event mask, breaking the workaround for the mozilla BadAccess bug.
When updating the clip region on cairo context (due to window changes or
paints of different sizes) we reset the old clip region, but this was
erronously done inside a cairo_save/cairo_restore pair, which made the
reset not take effect.
This fixes bug #592263.
Instead of doing some magic in gdk_draw_drawable() to avoid double
offsetting when calling gdk_draw_drawable on the impl we call
the vfunc directly on the impl. Thus removing the weird magic from
gdk_draw_drawable().
I tested this with the testgtk test "text", where if the original magic
code is disabled typing a newline in the middle of a text line causes
the double offset issue to appear.
When the clip mask is completely inside the drawable clip region we
don't change the clip at all. However, we did set region_tag_applied,
so when the drawable clip was removed we removed the original clip mask.
This is no good, so we fix that by returning early in this case.
Fixes issue reported in bug #592752.
The fallback pixbuf rendering case ends up calling gdk_draw_image() on the
destination drawable wrapper, which resets the previously set clip region.
So, we need to manually get the impl and draw on that directly.
This fixes bug 592752 where we don't clip pixbuf rendering on non-render
Xservers.
Some applications make weird assumtions on Gtk+ that do not work anymore
with the new client-side windows support. For instance SWT/Eclipse reorders
the stacking order of the X windows directly without telling gdk this,
which breaks gdk drawing as gdk now relies on knowing the stacking order
for window clipping.
This introduces a GDK_NATIVE_WINDOWS environment variable, which if set
causes Gtk+ to always use native windows. Its more compatible with
pre-csw Gtk+ behaviour if you do weird X-specific hacks, although it does
limit the size of GdkWindows to 65535x65535.
In validate_visible_area() it was assumed that gtk_tree_path_prev()
would always return the correct path of the preceding node. This is
obviously not true. The if-clause has been removed so that we now
always use _gtk_tree_view_find_path() to get the path from the tree,
node.
GtkCellRendererAccel also needs to acquire the GTK+ grab in addition to
a GDK keyboard grab. With the GDK keyboard grab, KeyPress and
KeyRelease events are delivered as usual, although we only want to
receive them for our grab widget.
Make the tooltip code a bit more robust for a case that only occurs when
GTK+ is used from a language binding. It looks like this case appears
because the memory management / ref counting is handled differently in
some of the language bindings. Instead of asserting, we will fail
silently. Also fix a think-o in gtk_tooltip_start_delay(). Patch from
O. Andrieu.
The previous code would trigger on an unmodified 'S' key for a
'Super+S' accel. The current code avoids that at the cost of breaking
combinations like 'Mod4+Super+S' which are too exotic to worry about...
Bug 591526
Shift-click inside an existing selection reduces the selection to the
range from the insert mark to the clicked point instead of removing the
selection. This makes GtkTextView more consistent with GtkEntry.
gdk_window_get_geometry calls the native function for all non-native
windows. This returns coords relative to the native parent. We need
to convert this to be relative to the client side parent.
This fixes DnD coordinates in firefox (bug 588437).
If antiexposures are queued and then we do the outstanding moves
we will queue translations that will affect incomming exposes
wrongly wrt the antiexposure. So, make sure we process the outstanding
moves before doing the antiexposure.
Additionally this commit adds a bunch of comments about how the
expose handling works and fixes a small bug that made us always
flush outstanding moves a little to early than necessary.
Set the input_window_destroy and input_window_crossing methods of the
GdkWindowImplIface on Windows. Add implementation of
_gdk_input_crossing_event that is mostly dummy, though.
Apps may change the window hierarchy while recursing over it by
destroying windows from the expose event handler. We need to copy
the children list and ref all the children while recursing.
This fixes some crashers in gedit (bug #589367, bug #591434)
The X11 queue_translation operation uses NextRequest to get the serial
of the XCopyArea operation where the translation should end. However,
if the gc passed to gdk_draw_drawable has a non-flushed clip region
(which it commonly has now for the window clipping) then the next
operation will be the GC flush, not the XCopyArea.
To handle this right we now pass in the GC to be used to
queue_translation and ensure that it is flushed before calling
NextRequest().
When we copy the region we need to also re-expose the areas of
the copied region that was not also in the destination.
And, we need to do this invalidation after the move, as the
move also moves any invalid area.
If there are outstanding moves in an area that intersects
the source of an outstanding move we need to move the invalid
area correspondingly, otherwise we will expose the wrong area
as the outstanding move copy will happen before we expose
the invalid area.
When moving an area we move any invalid region in this area to the
new place, but there really is no need to remove the old invalid
area as it would just be invalidated again (being newly exposed).
Previously, this flag wasn't cleared properly when the notebook lost
focus, but only when the notebook was focussed again later.
As this flag is only used to advance correctly focus pages by grabbing
focus to the new page after switching the page, this is not good.
In particular, it can cause a focus grab when programmatically switching
the notebook page and the focus is inside a completely different widget.
A previous attempt at this fix in
6e0af6c252 has been reverted in
dfe0c8c0ca because it didn't work
correctly.
This extends the usage of the native clear region call such that its
called also for windows that have parent relative background all the
way up to a native window. That way we get true background relative
background clearing even to a foreign parent, which means that some
transparent notification icons look right again.
GdkDrawable->draw_drawback was replaced with a new vfunc
draw_drawback_with_src that is now called from gdk_draw_drawable.
However, some code seems to call the vfunc directly (see bug #591288),
so make it chain to the new call.
Note that such direct vfunc calls are a bad idea and won't work for all
cases.
This moves the native show/hide calls to the generic code
for calculating viewable rather than in its own separate code
called from gdk_window_show/hide. This simplifies the code a bit,
but most significantly it means things are correctly shown when
they become viewable for other reasons than a show/hide call.
For instance, this fixes bug 590442 (gvim embedding) where the
toplevel GtkPlug is mapped by the embedder and we didn't previously
pick up that the native children became viewable and should be shown.
Print when Enter pressed in Name entry or Command Line entry in the
print dialog (#564695).
Add gtk_printer_option_set_activates_default() function and
gtk_printer_option_get_activates_default() function to control
behaviour of GtkPrinterOptionWidget.
We used to invalidate the whole window when raised, but this is
unnecessary much, we now just invalidate the visible area minus the
previously visible area.
This also fixes a problem where expose calling raise caused a loop (#588438)
This never worked before csw since the root window is never
set as IS_MAPPED, but with the new viewable check (which is
true for the root window) we could erronously queue exposes
on the root window.
This happened unexpectedly in bug 589369, where metacity
got a GraphicsExpose event on the root window due to some
graphics operation, queueing an expose which would be handled
by clearing that area. That is fixed with this commit.
When printing, increment page sequence before rendering of the page,
not after (#590084).
In opposite case it runs "end_page" function with wrong parameters when
drawing a page in another thread.
Add gtk_widget_get_visible(). For symmetry reasons and for convenience
when a widget's visibility state is available as a boolean condition,
also add gtk_widget_set_visible() (which simply calls show()/hide()).
Previously, this flag wasn't cleared properly when the notebook lost
focus, but only when the notebook was focussed again later.
As this flag is only used to advance correctly focus pages by grabbing
focus to the new page after switching the page, this is not good.
In particular, it can cause a focus grab when programmatically switching
the notebook page and the focus is inside a completely different widget.
Checks for details request before sending a job to a printer.
Shows busy state indication (cursor + status field).
This avoids printing to wrong printer (bug #576601).
This seems to more or less fix the build. On Tiger there are still issues
with libresolv missing on the link line, I will figure out what's up with
that soonish.
Properly invalidate iterators in iter_next, iter_children,
iter_nth_child and iter_parent when FALSE is returned. ListStore was
actually already mostly in order as the GSequence pointers are very
strictly checked, but to be a little stricter we've added stamp = 0
lines. TreeStore did not invalidate its iterators, so stamp = 0 lines
were added where appropriate. Unit tests have been added to check this.
Fixes bug 586374, reported by Mike Gemunde.
gtk_tree_view_enter_notify() now "ignores" the synthesized crossing
events. The synthesized crossing events always have (0, 0) as
coordinates, which messes things up. This patch does not fix all issues,
at least it makes the behavior much more reasonable again. Watch bug
555109 for further discussion on the issue.
Added checks to see whether the passed iterators are not the same in
convert_child_iter_to_iter() and iter_to_child_iter() functions in both
the sort and filter models.
Fixes bug 573321, suggestion by Vadim Godunko.
Adapt gtk_tree_view_get_path_at_pos() and
gtk_tree_view_get_drag_dest_row() to just return FALSE when bin_window
is NULL and not hit a warning. Makes this case consistent with the tree
view not having a model. Documentation has been updated to clarify
this, unit test has been added.
Fixes bug 539377, based on a patch by Bjorn Lindqvist.
Instead of failing with warning on !tree_view->priv->tree, return
silently when tree_view->priv->model is NULL. Clarified in the
documentation that for invalid paths (and every path is invalid when no
model is set), the function will fail silently although the current
cursor will be unset.
Fixes bugs 498010 and 546005.
Includes a test case for bug 546005 to start with, logic provided by
Paul Pogonyshev and Bjorn Lindqvist. In the future, we should maybe
merge treeview-scrolling.c with this one to create one large monolithic
tree view tester.
Instead of refiltering the recently used files we should rebuild
the list altogether when the current GtkFileFilter changes; this
allows us to keep showing the maximum amount of recently used
files.
Fixes bug:
http://bugzilla.gnome.org/show_bug.cgi?id=514260
gtk_tree_view_discover_dirty_iter() and gtk_tree_view_discover_iter()
have been in the tree forever, but unused since 1.3.8 or so. I guess we
no longer need them, so removed them. Fixes a compiler warning as well.
Bug #509650. Checks if all the predecesors (the parent widget,
his parent, etc) are visible. Only reports ATK_STATE_SHOWING when
all parents are visible.
Signed-off-by: Li Yuan <li.yuan@sun.com>
This lets us do this:
1. click on a folder in the shortcuts pane
2. start typing a filename
Then, the typed filename will actually go to the filename entry, like
the user expects. (Or to the search entry, in case the user clicked
on the Search shortcut.)
Also, removed the obsolete callback that made "/" and "~" typed in the
shortcuts pane bring up the location entry.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
People often do this:
1. Bring up a SAVE dialog
2. Click on a folder in the shortcuts pane
3. Start typing a filename
4. Oops! The interactive-search entry in the shortcuts pane appears.
With this, the shortcuts pane will not bring up the interactive-search entry. Then it
will be clear that you are not typing in the right place.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
We get the real pixmap size and use as cairo surface size rather
than doing some magic to try to get clipping on the right hand size
(and the magic looks wrong anyway).
The previous code could result in the width/height being to big for
the cairo 28.4 fix point size and thus not drawing anything.
This fixes bug #588076.
When the fallback for gdk_draw_pixbuf (gdk_drawable_real_draw_pixbuf)
is called with a window destination we have already applied any clip
regions and offsets for the window, but the window we get is a wrapper
and not an impl. We have to ensure we really draw to the impl, as
otherwise the pixbuf drawing will be clipped by client side subwindows.
This fixes bug 588553.
gdk_window_input_shape_combine_mask() can accept NULL for the mask
parameter, but it wasn't checking for NULL before passing the
resulting GdkRegion to gdk_region_destroy(). Fixes#589275
When the region is empty we can return early, because there
is no more area to remove. This happens often for children
of scrolled windows (i.e. things that are clipped out.
Previously, do_validate_rows() validated 300 rows per iteration. While
this is usually not problematic, as the typical tree view contains less
than 100 rows. Tree views with a lot of columns or complex cell
renderers could take inacceptably long, like:
- Epiphany's location bar entry completion has multiline and marked up
text in every cell. Validating a single row took ~1.5ms here.
- In the list view in Nautilus, When enabling all columns, validating a
single row would take ~3ms.
With 300 rows per iteration, that made those examples take 500ms/1s in a
signle main loop callback, and this obviously caused responsiveness
problems.
Now the code uses a timer and limits the time for validating rows to
30ms. This can cause less lines to be invalidated per call, so the
function might be called more often, but generally results in more
responsive applications.
Add the following functions based on a patch from Christian Dywan:
- gtk_widget_set/get_can_focus()
- gtk_widget_set/get_can_default()
- gtk_widget_has_default()
To fix this I replaced the code that creates an internal buffer
at init and construction time with code that creates a buffer
at _get_buffer() time, this is the same as GtkTextView does and
fixes the crashes for me.
We grab the default to the apply, forward or close buttons, as
appropriate. Also, make sure that the logic for setting the focus
to the best place on page change is applied to the initial page.
* gtk/gtksettings.c: (settings_install_property_parser): Handle enums too.
* gtk/gtktoolbar.c (gtk_toolbar_class_init): Move the gtk-toolbar-style and
gtk-toolbar-icon-size settings into GtkSettings because we now use it in
GtkToolPalette too.
* gtk/gtktoolpalette.[h|c]: Add gtk_tool_palette_unset_style() and
gtk_tool_palette_unset_icon_size(), and use the toolbar-style and
icon-size from GtkSettings if these are not set via the set functions.
* demos/gtk-demo/toolpalette.c (on_combo_style_changed),
(do_toolpalette): Add and handle a -1 value to mean the desktop "Default"
toolbar style.
Add a tooltip that shows the full path of the current folder, to avoid
ambiguity. We only show the tooltip when the expander is collapsed to
avoid cluttering the full file chooser.
* demos/gtk-demo/toolpalette.c (load_special_items): Demonstrate
gtk_tool_item_group_set_label_widget().
* gtk/gtktoolitemgroup.[h|c]: Rename the "item-group-name" property to
"label" because that is what it is. Likewise rename the functions.
Add a "label-widget" propert and get/set_label_widget() functions,
based on the same code/API in GtkExpander.
* gtk/gtktoolitemgroup.[h|c]: Rename the name property to item-group-name
and rename get/set_name() to get/set_item_group_name(), to avoid a clash with
GtkWidget::name.
* gtk/gtktoolpalette.h: GtkToolPaletteClass: Add padding for future use.
- gtk_widget_has_focus() for GTK_WIDGET_HAS_FOCUS()
- gtk_widget_get_sensitive() for GTK_WIDGET_SENSITIVE()
- gtk_widget_is_sensitive() for GTK_WIDGET_IS_SENSITIVE()
* gtk/gtktoolshell.c: Added vfuncs to get/set ellipsize, text-orientation,
text-alignment and size-group plus getter/setters to invoke these vfuncs.
* gtk/gtktoolitem.[h|c]: Added getters and setters to get/set these from the
parent GtkToolShell. This is in the style of the existing "properties".
* gtk/gtktoolbutton.c: Updated to use the extra properties.
* docs/reference/gtk/gtk-sections.txt
* gtk/gtk.symbols: Updated to mention the new functions.
These new "properties" are used by GtkToolPalette.
* gtk/gtktoolpallete.[h|cc]:
* gtk/gtktoolitemgroup.[h|cc]: Added a tool pallete container widget,
with groups of toolbar items that can be shown as a grid of icons
or a list of names.
* gtk/Makefile.am:
* gtk/gtk.h:
* gtk/gtkmarshal.list: Mentioned the new files.
Bug #567729
Implement _gdk_win32_window_destroy() by just renaming
_gdk_windowing_window_destroy(), removed superfuous stub.
Also cleaned up implementations of gdk_win32_window_set_background()
and gdk_win32_window_set_back_pixmap() - removed stuff now done at the
respective gdk_window_*() function.
Resurrcetion and adaption of find_window_for_mouse_event(). The window
receiving the WM_MOUSEMOVE, WM_?BUTTONDOWN is not necessarily the one
interested in GDK_(ENTER|MOTION|LEAVE)_NOTIFY
http://bugzilla.gnome.org/show_bug.cgi?id=588373
Also added some more more TODO_CSW and disabled print_event(): it can not
cope with the new _gdk_windowing_got_event() eating/morphing events.
The scrolling and region moving code needs to avoid drawing when the
window is mapped, which it did. However, it also needs to avoid
drawing when any of its parents are not mapped, which it didn't so
switch to using gdk_window_is_viewable().
This fixes the index rendering in evolution (#588169)
When we ungrab the pointer we don't get enter events for the window the
pointer is in at the time of the ungrab, so we manually query for the
window the pointer is in. The same thing actually happens on re-grab if
the previous grab was !owner_events (meaning we don't get crossing events
for windows other than the grab) but the new grab is owner_events (and
thus non-grab windows need to get crossing events).
This factors out some common code and enables it also for the re-grab
to owner_events case.
Paper size combo and orientation combo can be added by
gtk_print_operation_set_embed_page_setup_dialog() to GtkPrinUnixDialog
now. This function induce calling of
gtk_print_unix_dailog_set_embed_page_setup_dialog() after creation of
dialog. These two functions control embed-page-setup-dialog properties
in GtkPrintOperation and in GtkPrintUnixDialog.
There is also new function gtk_print_unix_dialog_get_page_setup_set()
which says whether page setup was set by user.
Selected page setup is stored as default page setup in
GtkPrintOperation.
New class is added, its name is GtkCustomPaperUnixDialog. The class
manages custom sizes. It is derived from GtkPageSetupUnixDialog's
CustomPaperDialog structure.
Page layout preview is modified, so, it shows dimensions of current
page setup (mm or inch - depends on locale). It also shows the name of
actual paper if page setup dialog is not embedded (paper size combo is
not visible).
gtk-demo is actualized to include this new feature.
If we get a nonlinear enter/leave notify on the toplevel we need
to set nonlinear in all the events we send, even if the in-toplevel
tree is linear.
This fixes combobox menus popping down immediately when you click
(not hold). (bug #587559)
Adds a 'model' type buffer for GtkEntry in which the actual
textual data is stored. GtkEntryBuffer can be subclassed.
Among other things, this allows GtkEntry to be used for secrets
that need to be stored in non-pageable memory. It also allows
buffers to be shared by entries.
See bug #576801.
We really need to wait for the MapNotify from the xserver to ensure
that the window has been mapped, as it may be delayed by the WM, network
or similar things.
This fixes a problem in the /ui-tests/keys-events gtk test
Add internal API for the default button box layouts to so we don't
need to call deprectated GTK+ functions (which are invisible with
GTK_DISABLE_DEPRECATED).
This is more important in the client side windows world, as clip masks
may be used for clipping to non-native subwindows. This fixes a bug
in aisleriot where it uses masked pixbuf drawing and it ends up drawing
over the moving card subwindow.
It turns out that mozilla, as per the gtk2xt code selects for input on
the socket with a mask of 0x0fffff (for god knows why) which includes
ButtonPressMask, causing a BadAccess if someone else also selects for
this. As per the client-side windows merge we always normally selects
for button press so we can emulate it on client side children that
selects for button press. However, we don't need this for GtkSocket,
so we unselect it here, fixing the crashes in firefox.
Turns out pygtk build broke due to the argument addition to draw_drawable.
So, we now add a new vfunc for the new draw_drawable and are thus
backwards compat.
we now use gdk_offscreen_window_set_embedder() instead of a signal
to get the parent. This also replaces set_has_offscreen_changes.
Rename "parent" in all embedding related names to "embedder" to make it
more obviously different than the normal parent.
Rename gdk_window_get_offscreen_pixmap to gdk_offscreen_window_get_pixmap
to match the other offscreen calls.
Rename gdk_window_offscreen_children_changed to gdk_window_geometry_changed
as this is more descriptive.
Going from print-to-file to a real printer and back used to nuke
an app-provided uri; now we keep the initial settings around to
avoid that. Fixes bug 587086.
We emulate visibility by unmapping (in X) all mapped (according to
gdk) windows that are not visible (all parents mapped). This is because
there may be client side windows inbetween the native windows in the
hierarchy, so you can't know a native window is visible just because
all the parent native windows are mapped.
However, we don't want to unmap foreign windows, as that may cause all
sort of unexpected issues. This should be safe, because generally the
parent of a foreign window is a native window (e.g. a socket), so its
gdk visibility state is the same as the Xserver one.
This fixes an issue with the GDM notification area where the unmap of
the plug caused spurious UnmapNotify events that confused GtkSocket and
caused icons to become one pixel wide.
Last commit was bad, as it didn't clip against client side
children. This implements such clipping first and then
only clears the rectangles that need to be cleared.
This is how cairo works with native children.
This fixes an issue where the drag target outline is visible on the
evolution folder treeview when it isn't with native windows.
Without this we can't draw to them, which caused problems for e.g.
gnome-settings-daemon clearing the background when the desktop
background changed.
Note: We don't actually clip away child windows from the root window,
the clip is just based on the size of the root window.
Reserving toggle space is nice for consistency in main menus
and context menus, but it gets in the way in special situations,
such as combo boxes, tabular menus, etc.
GtkNotebook used gdk_window_get_pointer() incorrectly, as it already
had coordinates from various GdkEvents. Using get_pointer() means
that you get pointer positions *after* the event has happened, which
leads to visual out-of-sync results, or inadvertently detached tabs if
you click on them while your machine is being slow.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Don't pass the click on the button through to the scale when the
dock popup will be moved, otherwise we could end up changing the
sound in unexcepted ways (to zero for vertical popups at the bottom
of the screen for example).
gtk/gtkmenuitem.c: Override custom_tag_finished() for "accelerator" and search
the correct toplevel GtkWindow to attach accelerators to menu items.
gtk/gtkwidget.[ch]: Added _gtk_widget_buildable_finish_accelerator() to allow
subclasses to specify a toplevel window to associate with when parsing <accelerator>
tags
We do want to have consistent padding in menus in menubars and context
menus, but the menus used in comboboxes don't need the extra padding.
Add private GtkMenu API for turning this off. Bug 564063
Setting a tooltip on a widget unfortunately triggers several roundtrips
to the X server. We reduce this overhead by only doing it if the
widget is visible, and by deferring to an idle. See bug 585626.
The virtual method list_shortcut_folders returns a GSList * of GFile *.
In turn, gtk_file_chooser_list_shortcut_folders() converts those to strings.
However, the delegate in gtkfilechooserutils.c was calling
gtk_file_chooser_list_shortcut_folders() every time, so we were trying
to convert invalid data.
Now we have an internal function that deals with GFile *. That
function is called by the delegate, and the conversion is done only
once by the API entry points.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
We can't set the sort column when we load the GtkFileChooser's settings, as the
file models may not have been created yet. Wait until the models are actually
present; then we can set the sort column.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
In the destroyed window case in do_synthesize_crossing_event we didn't
return a value which can cause infinite "loops". Always return FALSE
to make sure the idle doesn't run again.
Doing this directly had some issues with picking going recursive in
clutter-gtk. Furthermore, doing it in an idle means we can coalesce
multiple calls (which is common due to widget changes) in the same
toplevel to just one call.
You can call this if you have offscreen children and the geometry of
them changed. This will cause re-picking of the active window sending
enter and leave events as needed.
We want to be able to map any window coordinate to a root coordinate, not
just the origin, because you can't rely anymore on a simple translation
from window coordinates to parent with offscreen windows. This lets
us e.g. pop up menus in the right place even if they are popped up from
a no-window widget.
We use the offscreen signals for getting parent, picking
children at a point and mapping coordinates between windows
embedding offscreens and offscreens.
This means we have two hierarchies more or less, one visible to apps via
the standard APIs and for drawing where the offscreens are their own
separate toplevels, and another one for event handling where embedded
offscreens appear as if they were children of the embedding window.
3 signals are for offscreen windows
get-offscreen-parent: Get the parent window an offscreen is embedded in
to-parent: Convert coordinates from offscreen to parent
from-parent: Convert coordinates from parent to offscreen
1 signal is for the window embedding offscreens:
pick-offscreen-child: This picks what (if any) offscreen is at a specific position
The last signal is only used if you call gdk_window_set_has_offscreen_children
to tell gdk that the window has embedded offscreen children.
Add get-pointer signal for offscreen window pointer getting
Apps using offscreen windows can connect to get-pointer on offscreen
windows in order to make gdk_window_get_pointer() return correct
values.
Add get-offscreen-parent signal
Add signals for from-parent and to-parent coordinate mapping
Add pick-offscreen-child signal
We returned the innermost child that has the pointer, which is not right.
Only the direct child that has the pointer in it should be reported (if any).
This also removes the (unimplemented) possibility to change a window to
non-native. This seems generally not very useful, and there are some problems
with it, for instance if two "users" need a window to be native and then
one of the "users" doesn't need it anymore it can't change it back, because
it is unaware of the other reason the window is native.
If a native window or a window with a native subwindow is moved or resized
then the client window moves and implicit paints need to be flushed since
the native window move will copy/overwrite data. This may happen while there
is an outstanding paint if the move is inside an expose event (weird, but
flash embedded in webkit hit this).
Right now we're asserting here, but the right fix is to allow this but
to not flush the parts that are currently in a (non-implicit) paint. This
means we flush all results from previous not-yet-flushed exposes, but not
the ones being drawn.
Use the same code path to get a CGContext for both gdk_draw_* and
gdk_cairo_create and make sure we unlockFocus in both cases. This
fixes the broken rendering in GtkRuler. Also use an average of flush
intervals when checking whether we can flush or not, since otherwise
we get too sensitive and block almost all explicit flushes that are
caused by mouse movements for example.
Unfortunately the old GdkWindowObject is public and accessed
from macros, etc. So, we publish a limited copy of GdkWindowObject
and use the full one internally when building gdk.
In the new world offscreen windows are not put in the hierarchy, but are
rather toplevels for themselves. Offscreen hooks don't make any sense
in this model.
It often happens that we move region A to B and then we move a subset
of B to C. When possible we'd like to replace this with a move from
A directly to C, and a suplimentary move from A to the areas of B not
overwritten by C.
Getting an optimal move combiner seems quite complicated, but this
simple approach gets most of the interesting cases right and isn't
all to complicated.
There is no need to copy something that is already invalid and will
be marked as invalid in the destination anyway, so we remove this
area from the region to copy.
The expose translation is useful for tracking how outstanding
invalid (exposed on server) areas are copied, and how we need to
compensate for that on the client side to redraw the right area.
So, we should queue the translation at the time we actually move
the bits on the server side, not when moving the window on the
client side.
Also, clean up some naming of parameters.
We now copy outstanding window moves directly on the window and
not to an intermediary pixmap, this means our previous code to
combine window copies was wrong (it relied on each copy not
destroying the source date).
Furthermore, we can't just remove all the update area from the
destination of the outstanding moves, as sometimes things get
copied into that area and then used as the source of another
copy.
We replace the previous window copy combining with a naive
version that just queues each move, just to get things right.
Further work to optimize copies is possible.
Also, we don't remove copy destinations that are used as source
for later copies.
We also clean up the memory management by not having
move_region_on_impl taking ownership of the passed in region.
Apps that set no exposure mask rely on the system clearing things
to the window background, so we need to do this ourselves.
Also, don't do this on foreign windows, as they are not controlled
by us. In fact don't do exposes on foreign windows either.
This is required for the GtkSocket code, as it shows the plug child
even though the current cached state is (wrongly) that its already
mapped.
This makes blink work for non-local case in testsocket.
Native descendants of a virtual children are not automatically destroyed
with the parent as if it was a native window, so we need to handle
the native recursion tracking manually in _gdk_window_destroy_hierarchy()
It turns out that XCopyArea handling of obscured source regions is
buggy. It clears the destination area even outside the GC clip
region. We work around this for the pixmap->window case as that
can happen in gtk+ and is easy to work around.
X Bug report at:
http://lists.freedesktop.org/archives/xorg/2009-February/043318.html
Some apps really need to set custom event masks on native child windows,
for example emacs sets the event masks with gdk, but then reads out
the raw X events via a filter, so gdk event emulation doesn't work for that.
When we get motion or button events we map back from the event position and
window to the toplevel before doing anything, because a toplevel native window
could e.g. overlap a child window or whatever.
These are generated when we get an implicit grab on a native
child window, and we can't filter them with _has_grab() because
they are sent before the button press event where we detect
the implicit grab.
This makes clicks work in the flash plugin again
It turns out we really have to ignore grab/ungrab events or we'll
report double crossing events when we grab or ungrab.
However, we also can't ignore crossing events from grabs from other clients
as that leads to missed enter/leave events on e.g. alt-tab in metacity.
Fortunately we now track grabs very precisely, so we know with certainty
whether we have a grab at the time (serial) of the native crossing events,
and only if we do we ignore them.
If we get crossing events with subwindow unexpectedly being NULL
that means there is a native subwindow that gdk doesn't know about.
We track these and forward them, with the correct virtual window
events inbetween.
This is important to get right, as metacity uses gdk for the frame
windows, but gdk doesn't know about the client windows reparented
into the frame.
For instance if we grab the pointer and then check if its grabbed
so that we know to ungrab we don't care that the grab is not
yet active, so report the steady state (i.e. the last grab)
Having GDK_WINDOW_CHILD windows with root as the parent apparently works,
and metacity uses it. The current gdk_window_get_toplevel() returns the
root window for that, which is wrong, so we check that explicitly.
This causes all sorts of weirdness with pointer_over_window
being the rootwindow and then crashing gdk_window_get_toplevel() later.
With this metacity stops crashing madly.
To avoid drawing the window background of other windows in the area
where the window was we set the bg to none recursively. However, this
is quite costly it the moved window has many siblings. Furthermore, it
is uncommon that siblings overlap, so this cost has little gain.
So, we only set bg None on the parent, which means that there will
be some more flicker in the uncommon case of overlapping siblings.
These are sent when someone else grabs the pointer, and we don't
want to miss these expose events. For instance, we missed enter
and leave events on alt-tab.
There were some issues with these wrt out-of-sync grab information
in the client, but that should now be handled. So, it should work
or at least be fixable if we find some bug.
After a successful grab/ungrab we wait for an xserver
roundtrip until we change the tracked grab in GdkDisplay.
This way that data is always up-to-date wrt events comming in.
Get rid of invalidate_maybe_recurse and process_updates. Implement
_gdk_windowing_{before,after}_process_all_updates(), and keep track of
when we're inside process_all_updates in the common code so we know
when to flush windows. Implement
_gdk_windowing_window_process_updates_recurse by means of
setNeedsDisplayInRect: displayIfNeeded. Use the added window argument
in begin_paint_region to get the right window (the paintable is always
the impl window now).
Replace them with two new functions
_gdk_windowing_{before,after}_process_all_updates() that are called
around the guts of gdk_window_process_all_updates(). Add empty ones
for X11 (nothing more needed), quartz ones will be implemented next.
We use this in the added windowing function
_gdk_windowing_window_process_updates_recurse. The X11 implementation
just calls _gdk_window_process_updates_recurse directly, but at least
quartz will need to do some more work.
This fixes a problem where we used to set them on a native window, but we
never unset it becase when the pointer moved to another native window
we just set the cursor on that window. Always setting on the toplevel
fixes this.
This reverts commit 7cc15ec6ea1504133dfe6febbdb12615550bb966.
Its risky to convert all the events in a go like this, as it
increases the out-of-order issues. It also isn't a full solution
to the motion hint issue as it will only work for the events
we happen to convert. It would be better to use serials to
handle motion hinting.
This is the first stage in tracking keyboard grabs in the common code.
This lets us handle destroying or unmapping virtual window with a
keyboard grab.
If we only convert the first then motion hint emulation won't
work since we don't see the next motion even until we've
fully handled this one.
However, this changes a behaviour that has been like this since
the mists of time. I don't know if it could cause other issues.
I haven't seen any yet though.
There was a performance problem with the old flicker fixing
approach. For moved windows we copied the window data to the double
buffer pixmap and then back to the window with the rest of the
expose data. In some cases the copy from window data to pixmap was
very slow because the pixmap was allocated in system memory and
the window in video memory.
The new approach is to delay all window moves and then replay them
after the expose has drawn to the double buffer pixmap but before
drawing it to the window. Furthermore, we remove all exposed areas
from the destination of the delayed moves so we won't copy something
just to then immediately draw over it.
This makes scrolling in firefox fast, and it makes tests/flicker not
show any (detectable) flicker.
We return the raw window drawable, so its likely the app will do some
weird stuff to it, like draw using non-gdk operations. We don't want
the app to see any half-drawn state, so flush everything.
This fixes a scroll issue in firefox at least.
This fixes a mismatch in save/release gstate for the CGContext. If
this function is ever used for pixmaps, we need to add support for
that, probably will have to do so soon.
The one that puts windows outside the screen and moves them in when
showing. It might not be needed anymore and the workaround doesn't
work with the client-side window branch anyway because the window is
already mapped when we get showed for some reason.
If we do this there is a short window where we think there is a grab, and
if we generate a client side pointer motion event in this time (e.g. from
a window move) we could be delivering that according to the grab. But in
the Xserver that grab is infinitely short as it sends Press and then
Release immediately.
To see a problem from this, try using the scrollwheel to quickly scroll
in the testgtk list of buttons.
This is basically the same fix as was done for
gdk_window_move_resize_internal. We make sure not to move the native
child window contents twice and we don't copy data that was overwritten
by the moving of the native child windows.
Whenever a native window is moved this causes an immediate change in
the window (the window content is copied). This change conflicts can
conflict with outstanding moves or other cached changed, so we need
to flush all outstanding moves in the related windows.
To simplify the code for window move/resize the toplevel version was
split out to its own function.
Move native windows after recomputing so that we get the right new
shape before moving (and the implied copy). This means we're not
copying too much data.
Take into account the area of a moved window that contains native
subwindows, as these affect things in two ways:
First of all we shouldn't copy the original window location, as that
is copied by the native window move.
Secondly, we can't copy things that would end up copying from the
native window move destination, as the data that used to be there is
now destroyed by the native window move.
It can happen that another native window is re-shaped over the region to
be moved, this will not destroy the data (since we're unsetting the background
when we reshape), but it will mean we need to read from this window.
We already used INCLUDE_INFERIORS, but that only handle subwindows. We fix
this by doing the copy on the toplevel, offsetting the copy to compensate for
this.
All the calls that unset private->parent failed if that was
not a native window (impl), instead we need to find the impl window
for the parent. Add some helper functions for this and use them.
For move/resize of child windows, we really need to recursively unset
on the parent, because moving the window could expose other native
children of the parent.
In do_shape_combine_region, only unset background if we're changing
the bounding shape (i.e. not the input shape)
There is no need to do all these computations when moving toplevels
as that can't really change any visible regions. Nor will it cause
any exposes we need to handle.
move_region_on_impl() - doesn't need to copy anything if dx/dy == 0
Ensure that we queue an update when invalidating an empty area but we have outstanding moves
Temporarily unset background when moving native child windows
The history before this was kind of twisted as several different
approaches were tested, so that was all squashed into this initial
commit to hide the uninteresting changes and files that were later
removed.
Revert commit f4090b5c84, as that
conflicts with the client-side-windows work. Furthermore, that
change is already applied as part of the client-side-windows work.
2009-04-02 10:06:01 +02:00
1905 changed files with 458195 additions and 439672 deletions
cat $(top_srcdir)/build/win32/vs10/$(MSVC_SLN).sln | sed 's/11\.00/$(MSVC_FORMAT_VER)\.00/g' | sed 's/2010/$(MSVC_VER_LONG)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$(MSVC_SLN).sln
cat $(top_srcdir)/build/win32/vs10/README.txt | sed 's/vs10/vs$(MSVC_VER)/g' | sed 's/VS10/VS$(MSVC_VER)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/README.txt
create_vcxproj:
for F in `(cd $(top_builddir)/build/win32/vs10 && ls *.vcxproj)`; do \
case $$F in \
*) cat $(top_builddir)/build/win32/vs10/$$F | sed 's/v100/v$(MSVC_VER)0/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$$F \
;; \
esac; \
done
create_props:
for F in `(cd $(top_builddir)/build/win32/vs10 && ls *.props)`; do \
case $$F in \
*) cat $(top_builddir)/build/win32/vs10/$$F | sed 's/<VSVer>10<\/VSVer>/<VSVer>$(MSVC_VER)<\/VSVer>/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$$F \
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.
