AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
29ccd13e15
gtk2/gdk/win32/meson.build

61 lines
1.4 KiB
Meson
Raw Normal View History

meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
gdk_win32_sources = files([
gdk: Add Cairo context implementations for all backends And make the GdkCairoContext as abstract. The idea of this and thje following commits is to get rid of all Cairo code in gdksurface.c (and $backend/gdksurface-$backend.c) by moving that code into the Cairo context files. In particular, the GdkSurfaceClass.begin_frame/end_frame() functions (which are currently exclusively used by the Cairo code should end up being moved to GdkDrawContextClass.begin/end_frame(). This has multiple benefits: 1. It unifies code between the different drawing contexts. GL lives in GLContext, Vulkan in VulkanContext and Cairo in CairoContext. In turn, this makes it way easier to reason about what's going on in surface-specific code. Currently pretty much all backends do things wrong when they want to sync to drawing or to the frame clock. 2. It makes the API of GdkSurface smaller. No drawing code (apart from creating the contexts) needs to remain. 3. It confines Cairo to the Drawcontext, thereby making it way more obvious when backends are still using it in situations where it may now conflict with OpenGL (like when doing the dnd failed animation or in the APIs that I'm removing in this branch). 4. We have 2 very different types of Cairo contexts: The X/win32 model, where we have a natively supported Cairo backend but do double buffering ourselves and use similar surfaces and the Wayland/Broadway model where we use image surfaces without any Cairo backend support and have to submit the buffers manually. By not sharing code between those 2 versions, we can make the actual code way smaller. We also get around the need to create 1x1 image surfaces in the Wayland backend where we pretend there's a native Cairo surface.
2018-04-12 14:48:31 +00:00
'gdkcairocontext-win32.c',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
'gdkcursor-win32.c',
GDK W32: Another massive clipboard and DnD update Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection is mostly gone, and the word "selection" does not reflect the functionality of this object too well. Clipboard is now handled by a separate thread, most of the code for it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses clipdrop as a backend. The DnD source part is also put into a thread. The DnD target part does not spin the main loop, it just emits a GDK event and returns a default value if it doesn't get a reply by the time the event is processed. Both clipboard and DnD use a new GOutputStream subclass to get data from GTK and put it into a HGLOBAL. GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext, anticipating a similar change that slated to happen to GdkDragContext. OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0 to make GDK use the old LOCAL and DROPFILES protocols. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-24 16:27:11 +00:00
'gdkclipboard-win32.c',
'gdkclipdrop-win32.c',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
'gdkdevicemanager-win32.c',
'gdkdevice-virtual.c',
'gdkdevice-win32.c',
'gdkdevice-wintab.c',
'gdkdisplay-win32.c',
'gdkdisplaymanager-win32.c',
GDK W32: Another massive clipboard and DnD update Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection is mostly gone, and the word "selection" does not reflect the functionality of this object too well. Clipboard is now handled by a separate thread, most of the code for it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses clipdrop as a backend. The DnD source part is also put into a thread. The DnD target part does not spin the main loop, it just emits a GDK event and returns a default value if it doesn't get a reply by the time the event is processed. Both clipboard and DnD use a new GOutputStream subclass to get data from GTK and put it into a HGLOBAL. GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext, anticipating a similar change that slated to happen to GdkDragContext. OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0 to make GDK use the old LOCAL and DROPFILES protocols. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-24 16:27:11 +00:00
'gdkdrag-win32.c',
'gdkdrop-win32.c',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
'gdkevents-win32.c',
'gdkglcontext-win32.c',
'gdkglobals-win32.c',
GDK W32: Another massive clipboard and DnD update Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection is mostly gone, and the word "selection" does not reflect the functionality of this object too well. Clipboard is now handled by a separate thread, most of the code for it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses clipdrop as a backend. The DnD source part is also put into a thread. The DnD target part does not spin the main loop, it just emits a GDK event and returns a default value if it doesn't get a reply by the time the event is processed. Both clipboard and DnD use a new GOutputStream subclass to get data from GTK and put it into a HGLOBAL. GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext, anticipating a similar change that slated to happen to GdkDragContext. OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0 to make GDK use the old LOCAL and DROPFILES protocols. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-24 16:27:11 +00:00
'gdkhdataoutputstream-win32.c',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
'gdkkeys-win32.c',
GDK W32: Test for IME correctly ImmIsIME() doesn't work (always returns TRUE) since Vista. Use ITfActiveLanguageProfileNotifySink to detect TSF changes, which are equal to IME changes for us. Also make sure that IMMultiContext re-loads the IM when keyboard layout changes, otherwise there's a subtle bug that could happen: * Run GTK application with non-IME layout (US, for example) * Focus on an editable widget (GtkEntry, for example) * IM Context is initialized to use the simple IM * Switch to an IME layout (such as Korean) * Start typing * Since IME module is not loaded yet, keypresses are handled by a default MS IME handler * Once IME commits a character, GDK will get a WM_KEYDOWN, which will trigger a GdkKeyEvent, which will be handled by an event filter in IM Context, which will finally re-evaluate its status and load IME, and only after that GTK will get to handle IME by itself - but by that point input would already be broken. To avoid this we can emit a dummy event (with Void keyval), which will cause IM Context to load the appropriate module immediately.
2019-03-22 15:10:02 +00:00
'gdkwin32langnotification.c',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
'gdkmain-win32.c',
'gdkmonitor-win32.c',
'gdkproperty-win32.c',
'gdkscreen-win32.c',
'gdkvulkancontext-win32.c',
'gdkwin32cursor.h',
'gdkwin32display.h',
'gdkwin32id.c',
GdkWindow -> GdkSurface: File renames Rename all *window.[ch] source files. This is an automatic operation, done by the following commands: for i in $(git ls-files gdk | grep window); do git mv $i $(echo $i | sed s/window/surface/); git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ; done git checkout NEWS* po-properties po
2018-03-20 10:46:11 +00:00
'gdksurface-win32.c',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
])
gdk_win32_public_headers = files([
'gdkwin32cursor.h',
'gdkwin32display.h',
'gdkwin32displaymanager.h',
'gdkwin32dnd.h',
'gdkwin32glcontext.h',
'gdkwin32keys.h',
'gdkwin32misc.h',
'gdkwin32monitor.h',
'gdkwin32screen.h',
GdkWindow -> GdkSurface: File renames Rename all *window.[ch] source files. This is an automatic operation, done by the following commands: for i in $(git ls-files gdk | grep window); do git mv $i $(echo $i | sed s/window/surface/); git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ; done git checkout NEWS* po-properties po
2018-03-20 10:46:11 +00:00
'gdkwin32surface.h',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
])
build: Install the backend headers in the backend directories That's where they are in the sources and we include them from other headers. So make sure the directories match.
2019-05-06 18:09:03 +00:00
install_headers(gdk_win32_public_headers, 'gdkwin32.h', subdir: 'gtk-4.0/gdk/win32/')
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
build: Check for EGL support in libepoxy on Windows ...EGL support needs to be explicitly enabled during the build of libepoxy on Windows as it is not enabled by default on Windows. With this, we can add an EGL renderer for Windows that make use of Google's libANGLE, which is a library that translates OpenGL/ES calls to Direct3D 9/11, which will provide better hardware compatibility on Windows and would act as one of the foundations to resolve issue #105.
2018-06-22 07:02:24 +00:00
GDK_WIN32_EGL_CFLAGS = []
if win32_has_egl
GDK_WIN32_EGL_CFLAGS = ['-DGDK_WIN32_ENABLE_EGL']
endif
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
gdk_win32_deps = [ # FIXME
GDK W32: Always set gtk-font-name to the active UI font. Fixes #1484 This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10". It also cleans up the code and uses some new pango API while at it. This was previously disabled in 9e686d1fb5cb20 because it led to a poor glyph coverage on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..) because the font fallback list was missing in pango. This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34 so enable it again when we detect a new enough pango version. (See !436 for the original MR)
2018-11-29 22:19:38 +00:00
pangowin32_dep
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
]
meson: gdk: fix static library names Fix double lib prefix in filenames (liblibgdk-xyz.a)
2017-03-30 23:15:08 +00:00
libgdk_win32 = static_library('gdk-win32',
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
gdk_win32_sources, gdkconfig, gdkenum_h,
include_directories: [confinc, gdkinc],
build: Check for EGL support in libepoxy on Windows ...EGL support needs to be explicitly enabled during the build of libepoxy on Windows as it is not enabled by default on Windows. With this, we can add an EGL renderer for Windows that make use of Google's libANGLE, which is a library that translates OpenGL/ES calls to Direct3D 9/11, which will provide better hardware compatibility on Windows and would act as one of the foundations to resolve issue #105.
2018-06-22 07:02:24 +00:00
c_args: ['-DGTK_COMPILATION', '-DG_LOG_DOMAIN="Gdk"', '-DINSIDE_GDK_WIN32'] + GDK_WIN32_EGL_CFLAGS,
meson: gdk: win32: add skeleton bits for win32 backend Won't even build, configure bits still missing.
2017-03-20 12:03:45 +00:00
dependencies: [gdk_deps, gdk_win32_deps])
Reference in New Issue Copy Permalink