Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent Fredric:
> On 21 April 2016 at 06:38, Ian Stakenvicius <a...@gentoo.org> wrote:
> > Well so far the only needs I have run into for the win32 flag has
> > been in relation to choosing UI toolkit support for cairo and gtk+
> > (and possibly others in the future), which is why I saw the
> > parallel.
> 
> 
> Given you're not using the flag to indicate "works on win32" as such,
> but instead "compile using Win32 Widgets instead of something else",
> wouldn't a better name indicate that somehow?
> 
> The simplest thing I can think of that clears this confusion is a few
> extra characters:
> 
>   "win32gui", "win32ui"
> 
> Or something along those lines.
> 
> It doesn't require us to know what the exact binding keywords in
> microsoft terminology is used, and it clearly communicates "This is
> something to do with User Interfaces" as opposed to "Just
> linking/compiling slightly differently".

win32 is what the base API seems to be called all over in the wild.
The GTK+ configure flag is also --enable-win32-backend in gtk3 and
--with-backend=win32 in gtk2 (didn't personally check the latter).
Note that gtk configure actually also tracks platform_win32 and
os_win32 in there, which are different things (and just configure.ac
internal names). Former is true when host contains mingw, latter when
host contains mingw or cygwin.
When win32 gdk backend is enabled (which the propose USE flag would
do), then it will depend on a matching cairo backend of that, to be
able to do its own drawing on Windows. There's actually some stuff
about pangowin32 as well, not sure Ian has noticed that yet.

The GDK win32 backend uses what is called the win32 API. See e.g
https://en.wikipedia.org/wiki/Windows_API#Versions
For example a GdkWindow is created via CreateWindowExW, root of that
documentation is apparently at
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx

It doesn't use the Windows API higher level UI stuff, like wxWidgets
does, but only the low-level stuff, and then emulating the themeing as
best as it can right now, like Qt does. So in that way win32gui might
be misleading. win32 or win32api or winapi or I dunno.

Theoretically you can also build this stuff for consumption with wine.
Or maybe ReactOS?
Basically the only real point I have is that anything kernel_* to
control this probably doesn't make sense.


Mart

Reply via email to