This way, it can be set in GtkBuilder.
Also make sure to only ever look at the GTypes set in the formats, as
GtkDropTarget cannot deal with mime types.
Now, we just print a whitespace-separated list of GTypes and mime types.
This makes this neat for 2 things:
1. Parsing it (see next commit)
2. Using it in GtkBuilder (see commits after that)
In particular, the common case of supporting a single GType (or mime
type) looks like just printing the GType (or mime type), which in
GtkBuilder looks like
<property name="formats">GdkTexture</property>
Usually the "dnd-finished" signal will be used to unref the GdkDrag. In
those cases, we would lose the object, so that when we do the final
drag_drop_done() afterwards, we wouldn't have a remaining reference.
With the reference guard, this now works.
It is good practice for (floating) window managers to respect explicit
position hints from clients (as long as the window wouldn't end up
off-screen etc.).
Before commit 13d3afa56e, GTK had a flag for setting the PPosition hint,
but now does so unconditionally. However the real intention is to *not*
request a fixed position, so don't do that.
Currently we use layout coordinates and widget height when determining
where a click or drag has happened. If the widget has top padding (which it
does inside a GtkEntry, for example), the area where it's possible to select
text is shifted down, so the part of GtkText above the layout is not counted
as the draggable area and instead the equal area below the widget is counted.
Since GtkText is always single-line, there's no need to do any of that and
we can use widget coordinates. Then the draggable area matches the widget
and the problems goes away.
The dummy Win32 window that we use to capture display change events and
to create dummy WGL contexts was created with CS_OWNDC, so we really do
not need to (and should not) call ReleaseDC() on the HDC that we
obtained from it, so drop these calls.
Since the shaders need to be updated for using with GLES (libANGLE at
least), default to WGL for now. Unfortunately it is not that common for
Windows to have GLES support, in which the easiest way to obtain such
support is via Google's libANGLE.
It turns out that the problem of the WGL window not drawing was due to
the fact that I messed up where I placed SwapBuffers() during the
conversion... doh:|
At the same time, stop storing the HDC in the GdkWin32GLContextWGL, but
instead always create it along the surface we created, so that it is ready
for use for operating with WGL when we are not dealing with "surfaceless"
contexts. If we are dealing with "surfaceless" contexts, just use the
HDC of the dummy window that we created when we created the
Gdk(Win32)Display.
WGL contexts should now be in working order at this point.
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.
nvidia sets the default draw buffer to GL_NONE if EGL contexts are
initially bound to EGL_NO_SURFACE which is exactly what we are doing. So
bind them to GL_BACK when drawing, as they should be.
See https://phabricator.services.mozilla.com/D118743 for a discussion
about EGL_NO_CONTEXT and draw buffers.
This way, one can force using WGL on Windows even if EGL support was
enabled. Also update the help text for gl-egl as it will apply for
Windows, albeit a bit later.
This has the benefit that we can refactor it and make sure we deal with
GdkDisplay::init_gl() not being called at all because
GDK_DEBUG=gl-disable had been specified.
It's not used there, but both backends have independent
immplementationgs for it.
I want to get rid of GdkGLContextX11 and moving code from it is the
first step.
Now that we have the display's context to hook into, we can use it to
construct other GL contexts and don't need a GdkSurface vfunc anymore.
This has the added benefit that backends can have different GdkGLContext
classes on the display and get new GLContexts generated from them, so
we get multiple GL backend support per GDK backend for free.
I originally wanted to make this a vfunc on GdkGLContextClass, but
it turns out all the abckends would just call g_object_new() anyway.
Instead of
Display::make_gl_context_current()
we now have
GLContext::clear_current()
GLContext::make_current()
This fits better with the backends (we can actually implement
clearCurrent on macOS now) and makes it easier to implement different GL
backends for backends (like EGL/GLX on X11).
We also pass a surfaceless boolean to make_current() so the calling code
can decide if a surface needs to be bound or not, because the backends
were all doing whatever, which was very counterproductive.
The code to create and manage a fake egl surface to bind to is
complex and completely untested because everyone seems to support this
extension.
nvidia and Mesa do support it and according to Mesa devs, adding support
in a new driver is rather simple and Mesa drivers gain that feature
automatically, so all future drivers shoould have it.
