We want a surface so we can properly represent the scale factor for it.
All backends are converted to use surfaces and we reimplement the
backwards compat code in the generic code.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
Include config.h first so that _GDK_EXTERN may be defined once
and only once during the build, so that we do not get warnings/
errors for macro redefinition.
https://bugzilla.gnome.org/show_bug.cgi?id=701251
Include gdkwin32.h (which includes gdkprivate-win32.h and gdkwin32cursor.h
during the build of GDK-Win32) so that
gdk_win32_icon_to_pixbuf_libgtk_only() and
gdk_win32_pixbuf_to_hicon_libgtk_only() get exported, so that the GTK
DLL can link correctly.
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
This is another step towards making GdkDisplayManager backend-agnostic.
Most of the backends profit from this as their atom implementations
where generic anyway - x11 needed that to allow multiple X displays and
broadway, quartz and wayland don't have the concept of displays.
The X11 backend still did things, so I only #if 0'd some code but did
not actually update anything.
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
When events are paused, we should not return TRUE from prepare() or check().
GTK+ handles this for events that are already in the GTK+ queue, but
we also need suppress checks for events that are in the system queue - if we
return TRUE indicating that there are events in the system queue, then we'll
call dispatch(), and do nothing. The event source will spin, and will never
run the other phases of the paint clock.
(Broadway doesn't have a window system queue separate from the GDK event queue,
but we write the function the same way for consistency.)
https://bugzilla.gnome.org/show_bug.cgi?id=694274
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.
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
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
(cherry picked from commit 5637ef1f97)
We now have a proper MASTER/SLAVE input device split, where
the masters are virtual core input devices and we add fake hw
slave devices for the system pointer and real slave devices for
wintab devices.
We also set the proper source_device on the events so you can
tell which device sent it and properly decode the axis info.
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
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 function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
This turns GdkWin32DragContext into a proper GdkDragContext subclass.
Because we now correctly initialize GdkWin32DragContext in
gdk_drag_context_new, we no longer crash immediatly when a DnD
operation is initialized (the find_window, drag_status, ... vfuncs
where all pointing to 0x0 instead of their proper win32 implementations).
We now try to consistently refer to GdkDragContext as "context",
GdkWin32DragContext as "win32_context" and the ole2 related
target_drag_context and source_drag_context as "ctx".
Members of GdkWin32DragContext only used by the ole2 DnD codepaths
are now explicitly marked with a ole2_dnd_ prefix.
We now do proper handling of existing invalid regions, and
we use ScrollDC which allows us to specify the right clip
region rather than just the bounding rect.
Positioning windows at 0,0 post creation failed, because it
was mapped with CW_USEDFAULT, but private->x/y still said 0,
so moving it to 0,0 did nothing. We now always position the
window at the right place, even when not mapped, but we
create it at CW_USEDEFAULT initially and store that position
before moving it to the right place.
This fixes the window sizing test in testgtk and the inital
position for the gimp toolbar.
The synaptics trackpad driver has some weird behaviour on scroll.
It pops up a window over the mouse pointer (looking like a scrollbar).
This has two problems:
* We get extra enter/leave events for the trackpad window
* We get back the trackpad window when we look for the window
under the mouse to deliver the mousewheel message.
So, we add some trackpad specific hacks to avoid this (sigh) based
on the trackpad window window class.
This fixes bug #542777 and was partially based on a patch there
from Peter Clifton.
gdk_flush() should gdk_display_sync() on all open displays.
Both for display_flush and display_sync it seems useful to call
GdiFlush, but we don't have anything extra to do for display_sync,
as there is no inherent roundtrip on win32.
This should close bug #84314
Windows with transients: center on parent
Splash screens: center on monitor
Also properly ignores initial moves of unmapped
windows that are not override redirect or HINT_POS
Fixes bugs #324254 and #612359
There were still cases where we didn't get a WINDOWPOSCHANGED after
a SetWindowPos() call, like e.g. with a larger minimum size than
the set size (bug #574935)
So, we revert the previous fix and now just always manually emit
a configure notify after the move_resize call. Also, we inhibit
the WINDOWPOSCHANGED configure event during the move_resize operation
to avoid multiple Configures.
There are some cases where we don't get a WINDOWPOSCHANGE such that
we generate a configure event, even if we called gdk_window_move_resize()
or similar. For instance:
* The window is fullscreen
* The window is maximized
* The specified pos/size is the same as the current one
However, as per X11 ConfigureNotify semantics we *always* want one, or
we could run into issue like e.g. bug #537296 where we're waiting for
the CONFIGURE to call gdk_window_thaw_toplevel_updates_libgtk_only().
We always get the WM_DESTROY message anyway, and we remove it there.
Bug #336416 even claims this could be a leak if the WM_DESTROY
message was not seen before the DestroyWindow call returned, as
the WM_DESTROY message could not be handled later without the
window in the handle table. I'm not sure this can happen, but we
might as well remove it.
There is no particular reason to special case this, we want to handle all
sort of normal events. The only special thing we keep is that
as an optimization we pump the message loop extra during a WINPOSCHANGED
in a modal operation as that will cause us to repaint faster.
Also, bump the arbitrary number of mainloop iterations for the timer.
I don't see why we need it at all, but at least doing more than one
iteration if needed should be nice.
When you start a window resize or move via the window menu and
don't actually change anything we're not getting an exitsizemove.
In order to work around this we also look for WM_CAPTURECHANGED.
This moves all the code from WM_SIZE, WM_MOVE, and WM_SHOWWINDOW into
one place, cleans up the code and makes sure we only send a single
configure event even if both size and position changes.
We don't pass in raise anymore, but already_mapped.
Also, already_mapped must be used rather than MAPPED, as we already
synthesize the MAPPED in the generic code (and thus we don't have
to synthesize it again).
Calling PeekMessage can cause reentrant calls into the window procedure
for sent (as opposed to posted) messages, so its not safe to call
when we're not expecting reentrancy. Instead we call GetQueueStatus
when we're just looking for availible messages.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=552041
