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

73 lines
1.7 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',
Add new GdkDeviceWinpointer type
2021-07-02 08:53:16 +00:00
'gdkdevice-winpointer.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
'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',
Split out WGL/EGL stuff and simplify things This commit attempts to split GdkWin32GLContext into two parts, one for WGL and the other for EGL (ANGLE), and attempts to simplify things a bit, by: * We are already creating a Win32 window to capture display changes, so we can just use that to act as our dummy window that we use to find out the pixel format that the system supports for WGL. We also use it to obtain the dummy legacy WGL context that we will always require to create our more advanced Core WGL contexts. * Like what is done in X11, store up the WGL pixel format or the EGLConfig in our GdkWin32Display. * Ensure we do not create the dummy WGL context unnecessarily. In this way, we can successfully create the WGL/EGL contexts, however there are some issues at this point: * For WGL, the code successfully initializes and realizes the WGL Contexts, but for some reason things became invisible. When running gtk4-demo, this can be verified by seeing the mouse cursor changing when moved to spots where one can resize the window, although they were invisible. * For EGL, the code initializes EGL but could not realize the EGL context as shaders failed to compile. It seems like the shader issue is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
'gdkglcontext-win32-wgl.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
'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',
Initialize WinPointer and enumerate devices
2021-07-02 09:13:06 +00:00
'gdkinput-winpointer.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 = []
build: Add a HAVE_EGL define to config.h
2021-10-05 02:14:57 +00:00
if have_egl
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 = ['-DGDK_WIN32_ENABLE_EGL']
Split out WGL/EGL stuff and simplify things This commit attempts to split GdkWin32GLContext into two parts, one for WGL and the other for EGL (ANGLE), and attempts to simplify things a bit, by: * We are already creating a Win32 window to capture display changes, so we can just use that to act as our dummy window that we use to find out the pixel format that the system supports for WGL. We also use it to obtain the dummy legacy WGL context that we will always require to create our more advanced Core WGL contexts. * Like what is done in X11, store up the WGL pixel format or the EGLConfig in our GdkWin32Display. * Ensure we do not create the dummy WGL context unnecessarily. In this way, we can successfully create the WGL/EGL contexts, however there are some issues at this point: * For WGL, the code successfully initializes and realizes the WGL Contexts, but for some reason things became invisible. When running gtk4-demo, this can be verified by seeing the mouse cursor changing when moved to spots where one can resize the window, although they were invisible. * For EGL, the code initializes EGL but could not realize the EGL context as shaders failed to compile. It seems like the shader issue is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
gdk_win32_sources += ['gdkglcontext-win32-egl.c']
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
endif
Initialize WinPointer and enumerate devices
2021-07-02 09:13:06 +00:00
gdk_win32_deps = [
pangowin32_dep, # FIXME
cc.find_library('hid'),
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,
build: Use a consistent style for Meson files
2020-12-15 12:31:38 +00:00
include_directories: [ confinc, gdkinc ],
c_args: [
'-DGTK_COMPILATION',
'-DG_LOG_DOMAIN="Gdk"',
'-DINSIDE_GDK_WIN32',
Raise _WIN32_WINNT macro to target Windows 7 API
2021-06-29 12:27:13 +00:00
'-D_WIN32_WINNT=0x0601',
'-DWINVER=0x0601',
build: Use a consistent style for Meson files
2020-12-15 12:31:38 +00:00
] + GDK_WIN32_EGL_CFLAGS,
dependencies: [ gdk_deps, gdk_win32_deps ],
)
Reference in New Issue Copy Permalink