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.
-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
Now halfleft/halfright/fullup snaps do hug screen edges as intended.
Documents AeroSnap behaviour when snapped windows are drag-resized
(currently this implementation handles this in a very simplistic way).
Don't believe GTK when it tells us that window shadow is 0, preserve
previous values (but do remember that GTK wants no shadow, in case
we need that).
Fixes a couple of bugs in unsnapping (check offset against the half
of the window; don't put pointer in the middle of the window vertically
if it still fits in the top half).
https://bugzilla.gnome.org/show_bug.cgi?id=763013
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
Indicator is a bare layered click-through native window,
painted completely by GDK, including animation.
This commit also isolates some of the more spam-ish debug logging
under ifdef.
This commit also changes the system metric used for maximal window
height for the snapping purposes. Turns out, SM_CYMAXTRACK is way
too large, use SM_CYVIRTUALSCREEN instead.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This implements the part of AeroSnap that snaps windows when you
drag them (while moving or resizing) to the edge of the screen.
It also fixes drag behaviour for snapped and maximized windows
(if such windows are dragged, first they must be unmaximized/unsnapped).
Note that this code does not take into account the shadow width, and
because of that the under-pointer-position-preserving window moves
might not look as such for maximized windows, which lack the shadow
when maximized, but do have the shadow when unmaximized.
This commit also doesn't cover some corner-cases the same way AeroSnap does.
Also, the snapping indicator (which is supposed to be a window shape that
shows where the window will be if the drag op is stopped at its current
point) is not being drawn, all routines responsible for its creation,
moving and drawing are stubs.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This is what AeroSnap does. If a window is being unsnapped on
a new monitor, check if the work area is large enough for the
window to fit in its normal size. If the window fits, just
reposition it so that the ratio of
left-window-edge-to-screen-edge / right-window-edge-to-screen-edge
remains the same, without scaling the window.
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
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
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
* 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
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
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 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."
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
2005-11-09 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkwindow-win32.h (struct _GdkWindowImplWin32)
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_init,
gdk_window_get_type_hint, gdk_window_get_type_hint): Store the
type hint. Implement gdk_window_get_type_hint() by just returning
the hint stored.
2005-03-16 Tor Lillqvist <tml@novell.com>
* gdk/win32/gdkprivate-win32.h
* gdk/win32/*.c: Drop global variable _gdk_root_window, just call
GetDesktopWindow(). Rename the GdkWindow* _gdk_parent_root to
_gdk_root.
* gdk/win32/gdkwindow-win32.h (GdkWindowImplWin32): Add
toplevel_window_type field.
* gdk/win32/gdkwindow-win32.c: As there is only one root
window in GDK on Win32, we can compare directly to _gdk_root
instead of checking the window type.
(gdk_window_reparent): When reparenting a child of the desktop
clear out the window decorations. Correspondingly, when
reparenting to the desktop, add decorations. As in the X11
backend, save the window type of a toplevel window when
reparenting, in case it is reparented back to toplevel.
Tue Dec 8 09:41:00 2003 Tim Evans <t.evans@aranz.com>
* gdk/win32/gdkwindow-win32.[ch]: Implement
gdk_window_set_icon_list() for Win32, with support for big and
small icons and support for alpha-channel icons under Windows
XP. Replaces the previous implementation of gdk_window_set_icon().
(#128762)
2003-08-04 Hans Breuer <hans@breuer.org>
* gdk/win32/gdkwindow-win32.c(gdk_window_set_modal_hint) :
set HWND_NOTOPMOST for modal==FALSE, fixes bug #118435
* gdk/win32/gdkwindow-win32.c : implement gdk_window_[un]fullscreen
(gdk_window_{move,resize,move_rezize})) : noop if FULLSCREEN
* gdk/win32/gdkwindow-win32.c (gdk_window_set_icon) :
against all expectations it is basically ony a call with WM_SETICON
needed (the visual effect is there, though colors or mask are
still somewhat wrong).
* gdk/win32/gdkwindow-win32.h : place to store the HICON
* gdk/win32/gdkdrawabke.win32.c : readded the conditional end
pixel drawing as it was fixed at 1999-08-23
gtk/gtk.def : updated
2003-08-02 Tor Lillqvist <tml@iki.fi>
Fix gdk/win32 window geometry handling again. The window position
in a GDK_CONFIGURE event should be that of the client area, not of
the window decorations. (I was confused by the term "window
border" in X11. It does *not* mean the window manager
decorations. There are no X11-style window borders in Win32.)
Also, this time do take the geometry hints into account
appropriately when moving windows. Now testgtk's gravity test's
move buttons work OK. There are stil problems with taking gravity
into account when showing a hidden window.
* gdk/win32/gdkwindow-win32.h: Keep a whole GdkGeometry as hints
instead of separate fields.
* gdk/win32/gdkevents-win32.c (handle_configure_event): Don't
adjust for decorations.
* gdk/win32/gdkwindow-win32.c (get_outer_rect,
adjust_for_gravity_hints): New functions.
(gdk_window_move, gdk_window_resize, gdk_window_move_resize): Use
above functions, take geometry hints into account.
(gdk_window_set_geometry_hints): Size hints specicy client area,
not including decorations.
2002-03-01 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkwindow-win32.h (struct _GdkWindowImplWin32): Remove
the event_mask, it is now in GdkWindowObject.
* gdk/win32/gdkwindow-win32.c: Change accordingly. Set the
GDK_STRUCTURE_MASK in gdk_window_set_events(), as it is always set
in gdk_window_new(), too. (Bug#72921)
* gdk/win32/gdkevents-win32.c: Change accordingly here, too.
(vk_from_char): New function, calculates the virtual keycode
corresponding to the char in a WM_CHAR message.
(build_keypress_event, build_keyrelease_event): Use it.
(build_keypress_event): Call ImmReleaseContext() after using the
input context. This might plug a memory or resource leak.
(build_key_event_state): Remove #if 0 code.
(gdk_event_translate): Actually, it would be preferrable to always
handle just the WM_KEYDOWN and WM_KEYUP messages, not WM_CHAR at
all, and thus drop the contorted logic with ignore_wm_char etc.
* gdk/win32/gdkkeys-win32.c: (gdk_keymap_get_entries_for_keyval):
Debugging output.
(gdk_keymap_translate_keyboard_state): Return correct value. (But
_gtk_key_hash_lookup() doesn't check the return value...)
2002-02-26 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkkeys-win32.c: Implement the functions that until
now just were non-functional stubs. For "hardware keycodes", we
use Windows virtual keycodes. Not scancodes, although that at
first might seem more low-level and a better match to X11
keycodes.
The Windows API is really mixed up and confused with respect to
scancodes and virtual keycodes. (Surprised?) Some scancodes are
generated by two keys on the keyboard (!), and although the
keyboard messages do have a flag to indicate which key the user
pressed, other API that take a scan code as input don't let you
specify which actual key you mean.
(update_keymap): Function to build a X11-like representation of
the keyboard. Each key has four keysyms: two levels (nonshifted
and shifted) and two groups (normal and with AltGr).
(gdk_keymap_get_direction): Use the codepage corresponding to the
thread's input locale, not the system codepage.
* gdk/win32/gdkglobals-win32.c
* gdk/win32/gdkmain-win32.c
* gdk/win32/gdkprivate-win32.h
* gdk/win32/gdkwindow-win32.h
* gdk/win32/gdkwindow-win32.c: Remove the input_locale and
charset_info fields from GdkWindowImplWin32. Input locale is
per-thread in Windows, and as GDK on Windows really only works
when the GDI interaction all happens in just one thread anyway,
this state can be global. Use globals _gdk_input_locale and
_gdk_input_codepage instead. Set these based on the thread's input
locale (keyboard layout, or which IME is active).
* gdk/win32/gdkevents-win32.c: Set the group and hardware_keycode
fields in GDK key events. On input locale change messages, set
the global state variables, and inform update_keymap() that it
has to rebuild the keymap.
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2001-10-28 Hans Breuer <hans@breuer.org>
* gdk/gdk.c gdk/gdkevents.c
gdk/win32/gdkcolor-win32.c gdk/win32/gdkdnd-win32.c
gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkfont-win32.c gdk/win32/gdkgc-win32.c
gdk/win32/gdkim-win32.c gdk/win32/gdkmain-win32.c
gdk/win32/gdkprivate-win32.h gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gdkwin32.h
gdk/win32/gdkwindow-win32.c gdk/win32/gdkwindow-win32.h :
static correct-ness, underscore prefixing of library internal
functions
(applied the undisputed and the win32 part. Of the latter
I'm probably the one who will change it back again, if Owen
decides that the Gdk*Impl types should not be private to Gdk)
* gdk/gdk.def : added the remaining exported functions
2000-07-25 Tor Lillqvist <tml@iki.fi>
* Makefile.am: Include the build directory.
* configure.in: Generate build/Makefile and build/win32/Makefile.
* config.h.win32: Add USE_GMODULE and USE_MMX for gdk-pixbuf.
* gdk/gdk.def
* gtk/gtk.def: Updates.
* gdk/makefile.mingw.in: Define GDK_COMPILATION. Link with
PANGOWIN32_LIBS and gdk_pixbuf.
* gdk/win32: Compiles, but no doubt doesn't work at all.
* gdk/win32/makefile.mingw.in: Define GDK_COMPILATION.
* gdk/win32/gdkinput.c: New file, temporarily.
* gdk/win32/gdkinput-win32.h: New file
* gdk/win32/gdkinputprivate.h: Remove.
* gtk/gtkrc.[ch] (gtk_win32_get_installation_directory): Renamed and
made externally visible.
2000-07-23 Tor Lillqvist <tml@iki.fi>
More work on GDK for Win32. Still in an intermediate state.
* gdk/makefile.cygwin
* gdk/win32/makefile.cygwin: Removed.
* gdk/makefile.mingw.in
* gdk/win32/makefile.mingw.in: New files.
* gdk/Makefile.am
* gdk/win32/Makefile.am: Generate and distribute them.
* gdk/win32/gdkwindow-win32.h
* gdk/win32/gdkdrawable-win32.h
* gdk/win32/gdkpixmap-win32.h: New files.
* gdk/win32/gdkcolor-win32.c
* gdk/win32/gdkcursor-win32.c
* gdk/win32/gdkgc-win32.c
* gdk/win32/gdkimage-win32.c
* gdk/win32/gdkprivate-win32.h
* gdk/win32/gdkwin32.h: Update data structures. Cosmetics:
don't use fields and variables called xcursor, xid, etc (leftovers
from the X11 backend).
