Fix the build after the branch wip/alexl/simplify-gdkwindow was merged, as
there are some changes that broke things in the Windows backend, namely:
-gdk_win32_input_shape_combine_region() should not be removed at this
point (though it is a stub--otherwise GDK/Win32 will crash)
-Some more code need to be removed due to the removal of items in the
above-mentioned merged branch
Also, like the X11 backend, do not allow the creation of native child
windows, and stop checking for subsequent child windows
(GDK_WINDOW_CHILD), so that we can clean things up a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
Commit d249e77 (API: screen: Remove gdk_screen_is_composited()) attempted
to update the GDK-Win32 for the removal of the API, but some parts were
missed. This updates the code so that things continue to build and run.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
This changes the group/level semantic.
Previously W32 backend used "group 0/1" to denote "AltGr OFF/ON"
and "level 0/1" to denote "Shift is OFF/ON".
Now "group" means "keyboard layout" and there can be up to 255 groups,
while AltGr and Shift are combined into a single level enum that
takes values between 0 and 4.
Unlike X, W32 doesn't do effective group overriding, meaning that
it will never tell the caller that a different group was actually
used (even for universal keys, such as Enter), because key symbol
table is completely fabricated and there's no point in trying to
save a few of kilobytes of RAM by not duplicating universal key
records for all groups.
Also contains many whitespace changes (tab elimination, fixed
indentation) and cleanup (axed a few global variables, these are
now accessed via the default keymap).
https://bugzilla.gnome.org/show_bug.cgi?id=768722
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
Implements gdk_win32_window_set_shadow_width().
Uses shadow width/height to adjust max tracking size, allowing
windows to be drag-resized to cover the whole desktop.
Also uses SM_C*VIRTUALSCREEN instead of SM_C*MAXTRACK.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
It works exactly like AeroSnap.
Except for shift+win+left/right, which is left for AeroSnap
to handle (AeroSnap takes action before we get the message,
so there's no way for us to override it).
The only thing that doesn't work is shift+win+left/right on
a maximized window, for reasons unknown at the moment.
This only implements winkey+stuff behaviour of AeroSnap,
not the drag-to-the-edge-and-something-funny-happens one.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
If a layered window was hidden and is made visible, erase its
contents before showing it. GDK will schedule a redraw, but until
then we generally don't want to show old contents.
https://bugzilla.gnome.org/show_bug.cgi?id=763783
This is achieved by sending undocumented message WM_SYSMENU
to the window.
Before doing that, the window is given WS_SYSMENU style
(to enable window menu) and some combination of
WS_MAXIMIZEBOX (for "Mazimize" item)
WS_MINIMIZEBOX (for "Minimize" item)
WS_SIZEBOX (for "Size" item)
depending on which operations are currently permissible.
WM_SYSMENU is processed by DefWindowProc(), which results
in showing the window menu. We remove extra styles
at the first opportunity (WM_INITMENU message), as they
alter the way our window is rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=763851
This removes the event_poll_fd global variable and the (ab)use of
get_default_display. It is also more consistent with other backends.
Also store display
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
1) MSDN says that the coordinates of the maximized window
must be specified as if the window was on the primary display,
even if nearest display where it ends up is not the primary display.
So instead of using nearest display work area verbatim,
use it only to account for taskbar size, while using
primary display top-left corner (0:0) as the reference point.
2) MSDN says that max tracking size is a system property, we
should just call GetSystemMetrics() and use that.
https://bugzilla.gnome.org/show_bug.cgi?id=762629
This prevents normal application windows (and other kinds of windows)
from being moved up in Z-order to be above windows that have the
always-on-top bit set. Doing so would make the previously-normal windows
in question also always-on-top implicitly.
Windows that are already always-on-top will be restacked on top of other
always-on-top windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=746745
Instead of handling WM_DISPLAYCHANGE on every GdkWindow, only handle
it on an ad-hoc hidden window we create when opening the display.
This has two reasons:
1) we want emit the display::size-changed signal even if there are no
gtk windows currently open
2) we want to emit the signal just once and not once for every window
https://bugzilla.gnome.org/show_bug.cgi?id=757324
Windows does not send any release key event for one of the shift keys
when both shift keys were pressed together. This commit solves
the problem by sending the extra release key event for the shift key
which was released as first, when the other shift key is released.
Other modifiers (e.g. Ctrl, Alt) do not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=751721
In particular this means that cursors are disposed of by the way of
g_object_unref(), not DestroyCursor (which is documented to not to be
used on certain kinds of cursors, and we can't tell which is which).
It should also alleviate any concerns about destroying cursors that
are still in use by other windows, except for cases where we would
somehow get our hands on a HCURSOR that someone else is using and we
make a GdkCursor out of it and later unref and finalize it while it
is still in use.
It also removes the need to call CopyCursor(), which makes animated
cursors into non-animated ones as a side-effect (supposed to be a bug,
but try explaining that to MS). Now cursors should be animated (if
the are set up as such in the OS).
https://bugzilla.gnome.org/show_bug.cgi?id=697477
Requires Vista and newer.
* Create surfaces with cairo_win32_surface_create_with_format
* Provide an rgba visual that can be distinguished from the system visual
* Make rgba visual the best available visual
* Enable alpha-transparency for all windows that we control
* Check for appropriate cairo capabilities at configure time
(W32 - 1.14.3 newer than 2015-04-14; others - 1.14.0)
* Check for composition support before enabling CSDs
* Re-enable transparency on WM_DWMCOMPOSITIONCHANGED
Windows that were created while composition was enabled and that were CSDed
as a result and will look ugly (thick black borders or no borders at all) once
composition is disabled.
If composition is enabled afterwards, they will return back to normal.
This happens, for example, when RDP session is opened to a desktop where a GTK
application is running. For W7/Vista windows will only re-gain transparency after
the RDP session is closed. For W8 transparency will only be gone momentarily.
Windows that were created while composition was disabled will not be CSDed
automatically and will use SSD (WM decorations), while windows that are CSDed
manually will get a thin square border.
If composition is enabled afterwards, these windows will not change.
This is most noticeable for system menus (popup menus are often generated
on the fly, system menus are created once) and some dialogues (About dialogue,
for example).
https://bugzilla.gnome.org/show_bug.cgi?id=727316
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
Use (cairo) input shape of the window to check whether a point is inside or not
inside the window.
If it is, let the default window procedure do its thing (which seems to be
working all right in all known cases).
If it isn't, override the default window procedure and tell WM what we think.
Don't do any of the above if the window has CSD-incompatible styles (WS_BORDER
or WS_THICKFRAME).
This is a crude kind of substitute for window input shape support (which W32
does not seem to have). Still probably enough to be positive about input shapes
support.
https://bugzilla.gnome.org/show_bug.cgi?id=733679
Get monitor on which the most of the window is located (nearest monitor if
window is not on screen), get its work area (area not occupied by taskbar or
any other bars) and use that for maxsize.
Previous default of 30000 meant that windows maximized onto full screen,
even covering the area where taskbar is.
https://bugzilla.gnome.org/show_bug.cgi?id=726592
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
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
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
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.
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
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().
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.
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
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.
- replace GdkNativeWindow with HWND, remove type casts
- no more GdkDisplayClass::get_drag_protocol but GdkWindowImpl::get_drag_protocol
- remove *_client_message*()
There are sure regressions but basic stuff seems to be working
again after all the API breakage done with comments like
"Win32 and Quartz need to be ported still."
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
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.
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
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.
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.
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.
2009-03-17 Tor Lillqvist <tml@novell.com>
Bug 575700 - Crash when moving a GtkWindow
* gdk/win32/gdkevents-win32.c (gdk_event_translate): Fix
embarrassing crasher bug introduced on 2009-03-11. A variable was
assigned a value only inside a GDK_NOTE but still used outside
that.
svn path=/trunk/; revision=22568
2009-03-11 Tor Lillqvist <tml@iki.fi>
Bug 570896 - gdkevents-win32.c(2947) : error C4053: one void
operand for '?:'
* gdk/win32/gdkevents-win32.c (gdk_event_translate): Fix
compilation error with MSVC. While at it add clarifying comments
and fix a typo in the debugging output.
svn path=/trunk/; revision=22515
2009-03-11 Tor Lillqvist <tml@iki.fi>
Bug 574794 - Can not resize shaped windows on Windows
* gdk/win32/gdkevents-win32.c (gdk_event_translate): On handling
WM_WINDOWPOSCHANGED, don't do anything if the position and size
hasn't changed. I am not exactly sure I understand why this helps
this particular bug.
svn path=/trunk/; revision=22511
2009-01-29 Tor Lillqvist <tml@novell.com>
Bug 559408 - Transparency lost when images are copied between GTK+
and the clipboard on Windows
The code in gdkselection-win32.c is simplified quite a lot. When
an image is stored on the clipboard from GTK+, only the "PNG" and
CF_DIB formats are advertised. PNG is our preferred format because
it can losslessly represent any image that gdk-pixbuf can handle,
even with alpha, unambiguously. CF_DIB is also advertised because
of its ubiquitous support in Windows software.
Delayed rendering is used as before, so for other data than text
nothing is actually stored on the clipboard until some app asks
for it.
It's pointless to advertise images formats like "image/png" or
"image/x-MS-bmp" that no other Windows application is going to
look for anyway. Likewise it's pointless to store text under
formats like "text/plain" or "UTF8_STRING". Just store
CF_UNICODETEXT. CF_TEXT will be available as a synthesized format
anyways.
Office 2007 offers and asks for images in PNG format using the
registered clipboard format name "PNG", so we do likewise. If the
"PNG" format is available that is preferred when copying to GTK+
from the clipboard.
Unfortunately Word 2007 still uses CF_DIB without handling
alpha. But PowerPoint 2007 uses PNG if available and handles alpha
correctly. Both Word and Powerpoint offer PNG with alpha nicely.
Firefox and IE7 offer images that contain alpha as 32-bit version
3 BI_RGB DIBs with the undocumented "extra" bytes actually being
alpha. Also, alpha is premultiplied into the RGB bytes, presumably
because that is how AlphaBlend() wants such DIBs. That is also
taken care of. At least for Firefox it easy to be sure that a
CF_DIB on the clipboard is from Firefox.
Also some general stylistic cleanup, comment improvements, and
improvements of debugging printout especially in the clipboard
handling. Those are not detailled below.
* gdk/win32/gdkprivate-win32.h
* gdk/win32/gdkglobals-win32.c
* gdk/win32/gdkgmain-win32.c: Move some globals that were used
only in gdkselection-win32.c to be local to that file.
* gdk/win32/gdkproperty-win32.c (gdk_property_change): Don't
bother checking if text to be placed on the clipboard consists of
only ASCII.
* gdk/win32/gdkselection-win32.c: Add static variables for a list
of GdkPixbuf-supported formats, well-known registered clipboard
formats for images, and for GdkAtoms for well-known image and text
formats.
(_gdk_win32_selection_init): Initialize above static variables.
(selection_property_store) (gdk_selection_property_get)
(_gdk_selection_property_delete): Don't use a FIFO of GdkSelProps
for a window after all, it breaks testtext. See bug #163844.
(gdk_selection_convert): When converting to the TARGETS format,
i.e. when the caller wants to know what clipboard formats are
available, if PNG is available we report just that and skip
CF_DIB, JPEG and GIF even if advertised.
If CF_UNICODETEXT is available, report only UTF8_STRING.
When converting to the UTF8_STRING format, i.e. when the caller
wants text from the clipboard, try just CF_UNICODETEXT. There is
no point in trying CF_TEXT as Windows will synthesize
CF_UNICODETEXT from CF_TEXT anyway, if some app has stored just
CF_TEXT.
When converting to the image/bmp format, i.e. when the caller
wants an CF_DIB image from the clipboard, we check if the DIB is a
version 3 32-bit BI_RGB one that is likely to actually contain
alpha in the "extra" bytes. Such a DIB is likely to have
premultiplied alpha even, at least in the case of Firefox 3 and
IE7. We then edit the DIB in-place into a version 5 one in
BI_BITFIELDS format and undo the alpha premultiplication.
In any case, prepend a BMP file header before letting go of the
data which will be fed to the gdk-pixbuf bmp loader by upper
levels.
(gdk_win32_selection_add_targets): If some kind of pixmap image
format is being added, actually advertise just PNG and
CF_DIB. Note that alpha won't be stored on the clipboard through
CF_DIB. This is because gdk-pixbuf's bmp loader doesn't save
alpha. Furthermore, few if any non-GTK+ Windows apps seem to
understand a version 5 DIB with proper alpha anyway.
(_gdk_win32_selection_convert_to_dib): Simplified muchly.
svn path=/trunk/; revision=22255
2008-11-04 Tor Lillqvist <tml@novell.com>
Bug 557212 - Problem with which window gains focus and is visible
* gdk/win32/gdkevents-win32.c (ensure_stacking_on_activate_app):
Only do the restacking for the active window of the
application. Seems to fix the problem.
(gdk_event_translate): Only call ensure_stacking_on_activate_app()
when the application is being activated, not deactivated.
svn path=/trunk/; revision=21756
2008-11-01 Tor Lillqvist <tml@novell.com>
Bug 558278 - Crash when calling a callback set by
gdk_add_client_message_filter()
* gdk/win32/gdkevents-win32.c (apply_event_filters): Rename from
apply_filters() so that it is clear that this function is for
GdkEventFilters only.
(print_event): Print more information for GDK_CLIENT_EVENT events.
(gdk_event_translate): When handling client filters, don't use
apply_event_filters(). Use similar code as in the X11 backend,
although not exactly, as the parameter list and return value
semantics of gdk_event_translate() is different.
svn path=/trunk/; revision=21748
2008-10-18 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkevents-win32.c (gdk_event_translate): On
WM_WINDOWPOSCHANGING, don't dereference windowpos in the debugging
output without setting it first.
2008-10-18 Tor Lillqvist <tml@novell.com>
Bug 556578 - GIMP windows stay on top of other windows
* gdk/win32/gdkevents-win32.c (ensure_stacking_on_unminimize)
(ensure_stacking_on_window_pos_changing)
(ensure_stacking_on_activate_app): Ignore unmapped windows in the
loops where we look for the lowest "transient-type" window.
(gdk_event_translate): Don't call
ensure_stacking_on_window_pos_changing() or
ensure_stacking_on_activate_app() for unmapped windows.
svn path=/trunk/; revision=21676
2008-10-04 Tor Lillqvist <tml@novell.com>
Bug 132501 - Make utility window translate to tool window in win32
Implement the utility window type hint. Such windows are kept on
top of other windows. Makes GIMP's toolbox and dock windows behave
more like in GNOME under metacity. Apply the same logic also to
windows marked with the dialog window type hint, and windows that
are transient for some other window. I'll call such windows
"transient-type" below.
* gdk/win32/gdkevents-win32.c (doesnt_want_key): Drop unused
variables.
(ensure_stacking_on_unminimize)
(ensure_stacking_on_window_pos_changing)
(ensure_stacking_on_activate_app): New functions to implement the
desired stacking order. Make sure that a window that is not
transient-type stays below any transient-type windows of the
application. When activating a non-transient-type window make sure
it rises as high as possible.
(gdk_event_translate): Call above functions on
WM_WINDOWPOSCHANGING, WM_ACTIVATEAPP and on WM_SIZE when
unminimizing. Improve debugging printout.
* gdk/win32/gdkwindow-win32.c (get_effective_window_decorations):
Handle utility windows like toolbar windows.
(gdk_window_new_internal) (update_style_bits): Give utility
windows the WS_EX_TOOLWINDOW extended style.
(gdk_window_set_title): If debugging "misc" or "events", make the
handle of top-level windows show up in their title bars. Very
useful when looking at debugging output.
(gdk_window_set_keep_above) (gdk_window_set_keep_below)
(gdk_window_set_modal_hint) (gdk_window_set_skip_taskbar_hint)
(gdk_window_set_skip_pager_hint): Add and improve debugging
printout.
(gdk_window_set_type_hint): Print hint symbolically in GDK_NOTE().
2008-10-04 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkmain-win32.c (_gdk_win32_window_exstyle_to_string)
(_gdk_win32_window_pos_bits_to_string): New debugging printout
functions. Decode the WS_EX_* and SWP_* bits.
* gdk/win32/gdkprivate-win32.h: Declare them. Define
GDK_DEBUG_MISC_OR_EVENTS for use in GDK_NOTE() to match either
"misc" or "events".
svn path=/trunk/; revision=21587
2008-08-27 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c:
* gdk/win32/gdkwindow-win32.c (show_window_recurse): Check if
the window's state has GDK_WINDOW_STATE_MAXIMIZED set before
calling ShowWindow (), and show using SW_SHOWMAXIMIZED or
SW_RESTORE accordingly. This fixes an issue where maximized
windows that are iconified do not restore back to maximized
when you click the taskbar. (#528975)
svn path=/trunk/; revision=21218
2008-08-21 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c (doesnt_want_key): Remove the checks
to see if the window is modally blocked. This doesn't get us anything,
and it confuses the search window in GtkTreeView (and potentially other
utility windows in other apps). (#520165)
svn path=/trunk/; revision=21180
2008-08-05 Tor Lillqvist <tml@novell.com>
Bug 544684 - Win64 issue, window handles are assumed to be 32-bit
* gdk/win32/gdkcursor-win32.c
* gdk/win32/xcursors.h: Change some gchar* to guchar* and vice
versa to avoid gcc 4.4 signedness warnings.
* gdk/win32/gdkevents-win32.c: Add some guchar and char pointer
casts to get rid of gcc 4.4 signedness warnings. Print GdkAtom
values in debugging output using the %p format.
* gdk/win32/gdkkeys-win32.c
* gdk/win32/gdkfont-win32.c
* gdk/win32/gdkmain-win32.c: Add some casts to avoid gcc warnings.
* gdk/win32/gdkwindow-win32.c: Use SetWindowLongPtr() instead of
SetWindowLong().
* gdk/win32/gdkwin32id.c (gdk_handle_hash): Use all 64 bits of a
HANDLE on Win64.
svn path=/trunk/; revision=20994
2008-07-24 Cody Russell <bratsche@gnome.org>
Bug 544510 – SetTimer callback signatures has the wrong type
* gdk/win32/gdkevents-win32.c: Fix modal_timer_proc() and
sync_timer_proc() to use UINT_PTR for the 'id' parameter
instead of 'id'. Patch by Richard Hult.
svn path=/trunk/; revision=20903
2008-07-21 Cody Russell <bratsche@gnome.org>
Bug 153567 – Repaint glitches in widgets
* gdk/win32/gdkevents-win32.c: Set a sync timer when
we receive WM_SYNCPAINT, and RedrawWindow() once
the timer expires.
svn path=/trunk/; revision=20881
2008-07-02 Cody Russell <bratsche@gnome.org>
Bug 541162 – [Win32] Update for the new GdkWindowImpl stuff
* gdk/win32/gdkprivate-win32.h:
* gdk/win32/gdkgeometry-win32.c:
* gdk/win32/gdkevents-win32.c:
* gdk/win32/gdkwindow-win32.c: Update Win32 backend according to
the newly refactored GdkWindow code.
svn path=/trunk/; revision=20729
2008-07-01 Cody Russell <bratsche@gnome.org>
Bug 539164 – Windows' System Menu blocks main loop
* gdk/win32/gdkevents-win32.c: Use a modal timer proc in between
receiving WM_ENTERMENULOOP and WM_EXITMENULOOP and pump the
GLib mainloop from there.
svn path=/trunk/; revision=20726
2008-05-30 Tor Lillqvist <tml@novell.com>
Bug 533108 - leak of GDI region in function 'handle_wm_paint'
* gdk/win32/gdkevents-win32.c (handle_wm_paint): Patch by Daniel
Atallah.
svn path=/trunk/; revision=20250
2008-05-06 Richard Hult <richard@imendio.com>
* gdk/gdkevents.c: (gdk_event_copy), (gdk_event_free):
* gdk/gdkinternals.h: Add private backend data to events, and
handle it when copying/freeing events. Currently only needed in
the quartz backend.
* gdk/directfb/gdkevents-directfb.c:
* gdk/quartz/gdkevents-quartz.c:
* gdk/win32/gdkevents-win32.c:
* gdk/x11/gdkevents-x11.c: (_gdk_windowing_event_data_copy)
(_gdk_windowing_event_data_free): Add stubs for X11, win32 and
directfb. Implement for quartz. Part of fixing bug #473822.
svn path=/trunk/; revision=20078
2008-03-23 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c (show_window_recurse):
Check window state for GDK_WINDOW_STATE_ICONIFIED before doing
ShowWindow (SW_RESTORE). This fixes a problem where tearing off
menus from a maximized window would force the window to restore
its size. (#518846)
svn path=/trunk/; revision=19926
2008-03-14 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkevents-win32.c: Drop the support for the
MSH_MOUSEWHEEL message that MSDN says is used only on NT 3.51 and
Win95. Thanks to mitch for noticing this obsolete code.
svn path=/trunk/; revision=19874
2008-02-07 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c
* gdk/win32/gdkwindow-win32.c: Fixed two declarations in the middle
of a block that were causing compile problems on old
compilers. (#515053, reported by Kazuki IWAMOTO)
svn path=/trunk/; revision=19493
2008-02-06 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c: Check if the window is a temp window,
otherwise things get wonky when you click on a menu. This fixes
a regression caused in #505928. Thanks to Tor for spotting this
one! (#514789)
svn path=/trunk/; revision=19482
2008-01-31 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c:
Refactored some of the window hiding/showing code from
WM_ACTIVATE to WM_SIZE and WM_SYSCOMMAND. Having this
under WM_ACTIVATE was causing the application to go into
a weird state when the user right-clicked on the taskbar
entry of a window that was minimized. (#505928)
svn path=/trunk/; revision=19451
2007-12-23 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c (show_window_recurse): Check that
the window is mapped before setting SW_RESTORE or SW_MINIMIZE.
Fixes a regression caused by #164537 patch where transient
windows that are hidden get shown (incorrectly) when their
parents are minimized. (#504984)
svn path=/trunk/; revision=19231
2007-10-19 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkevents-win32.c (gdk_event_translate): Add a block
around the WM_ACTIVATE case to avoid declaring variables in the
middle of a block. (#488017)
svn path=/trunk/; revision=18932
2007-10-17 Cody Russell <cody@jhu.edu>
* gdk/win32/gdkevents-win32.c
* gdk/win32/gdkwindow-win32.[ch]: Force non-modal transient dialogs
to iconify with their parents on Win32. Maintain a list of transient
children, and whenever a window is hidden or restored we now do the
same thing to all connected transient windows above and below the
current window in the chain. See comment under WM_ACTIVATE for the
reasons why. (#164537, #371036, #405178)
svn path=/trunk/; revision=18929
2007-07-12 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c
* gdk/win32/gdkwindow-win32.[ch]: Fix transient windows on Win32
so that when a transient child window is closed (particularly when
there are 3 or more levels of transient windows), the correct window
receives focus rather than a seemingly random window. (#112404)
svn path=/trunk/; revision=18461
2007-06-25 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkevents-win32.c (gdk_pointer_grab): Revert my
attempted overly simple fix for #445284, as it causes a
regression. (For instance, in GIMP the tool cursor gets used also
for the right-click menu in image windows.) A more complex fix is
needed to more completely emulate X11 behaviour.
svn path=/trunk/; revision=18225
2007-06-10 Cody Russell <bratsche@gnome.org>
* gdk/win32/gdkevents-win32.c (gdk_pointer_grab):
Don't revert the mouse cursor to the built-in one when
the user holds the mouse button down. (#445284, Tor Lillqvist)
svn path=/trunk/; revision=18093
2007-05-30 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkevents-win32.c (gdk_pointer_grab): Subtract the
multi-monitor offset from x and y before setting up the rectangle
for ClipCursor(). Fixes#442326.
svn path=/trunk/; revision=17988
