Windows support

[ntd]

Does LGI support Windows? Has anyone succeeded in running GTK+ application on it? I'll probably need that in the near future but I actually do not own a Windows box so any information would be appreciated.

[pavouk]

Theoretically there should be no problem in lgi itself. I guess that the most problematic part would be getting runtime GLib environment incl. fully functional GObjectInterospection. However, someone else has to do the actual work, I'm hopefully not going to touch windows again :-)

[ntd]

Thanks for letting me know. When (and if) I'll try to port that stuff, I'll report my progress here. Fill free to close this if you don't want an open issue hanging around for ages.

[felselva]

Eventually, I will have to touch Windows, again, for a commercial project. I think using the MingW compiler is the best choice to support Windows. The MingW provides the GNU project libraries, like glib and gtk+, on Windows. However, I will not be able to make the tests right now.

[ntd]

AFAIK MingW provides a basic win32/64 toolchain but you must compile everything else (GLib and GTK+ included) by yourself.
I'm maintaining a MingW GTK+ environment for cross-building my applications on Windows and, up to now, my two main concerns are:

1. there is no gobject-introspection;
2. more often than not, everything works under Wine but doesn not on Windows.

So I could theoretically work on the former but I cannot test because of the latter.

[nnesse]

I was also planning on trying to use LGI on windows soon. I was going to try to use the GTK packages provided by the MSYS2 project. I haven't tried it yet but I see there are packages for GTK3 and gobject-introspection: https://github.com/Alexpux/MINGW-packages

[felselva]

@ntd Looks like this is the same problem for PyGI (I never used it by myself, though). Seems this is not an issue of LGI, then. Maybe the link @nnesse provided is the best shot.

[nnesse]

I managed to get LGI to work in a MSYS2 environment. Here's a branch that shows how I did it: https://github.com/nnesse/lgi/tree/msys2.

I followed the standard install procedure then synced the mingw64 packages. I had to build LUA myself since the MSYS2 package didn't build it as a DLL. I made some minor changes to the Makefile and declared the luaopen function with "__declspec(dllexport)". With that I was able to run the gtk-hello sample.

One thing that tripped me up for longer than it should have was that I specified MSYS paths for LUA_PATH and LUA_CPATH...

[ntd]

Finally I managed to cross-compile gobject-introspection (see https://bugzilla.gnome.org/show_bug.cgi?id=658126 for the progress). Porting lgi was relatively straight-forward and involved a fistful of (hopefully) unobtrusive patches, similar to what already done by @nnesse .

Now I'm able to succesfully run samples/cairo.lua on ArchLinux with wine but anything GTK+ related does not show up. When I run this code:

local lgi = require 'lgi'
local Gtk = lgi.require('Gtk', '3.0')
local window = Gtk.Window {
    type = Gtk.WindowType.TOPLEVEL,
    child = Gtk.Label { label = 'Show me! Show me! Show me!' }
}
window:show_all()
Gtk.main()

the windows are arranged to accomodate the new toplevel (I'm using a tiling window manager) but then the display content is not updated. Any suggestion on where to look for?

[ntd]

Ah, I forgot to add gtk3-demo.exe with wine runs correctly, so the problem should be gobject-introspection or lgi specific.

[ntd]

No idea if this is relevant but apart from a warning from Pango and the missing canberra module (I see both of them all the time when running GTK+ apps in MinGW) the only error reported (that I've never seen before) is the following one:

err:ntdll:RtlpWaitForCriticalSection section 0x24f230 "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec)

I see it after 5 seconds and then periodically every 60 seconds.

[pavouk]

Wow, this is pretty good progress. I'm not sure where the issue with GTK not working can be. Maybe it would be useful to try to compile PyGObject and try Python version of that minimalistic program above. If it works, the problem might be somewhere in lgi, otherwise it would look like an issue with GObject or GObjectIntrospection port.

[ntd]

Finally I found the root cause of the rendering issue: it is the GDK thread locking called by lgi. If I remove or comment https://github.com/pavouk/lgi/blob/master/lgi/override/Gdk.lua#L23 everything starts working as expected.
Not sure what to do now. This should be enough for my own purposes though: I intend to include lua-lgi in the windows installer of a project I'm currently working on that does not use threads.

[ntd]

I just finished cross-compiling a Windows installer that includes lgi and a complete GTK+3 environment. It is targeted to my library but the Lua interpreter can be used for playing with plain LGI and GTK+:

It is tested only under Wine so any feedback on a real Windows platform will be appreciated.
The installer can be downloaded from SourceForge and here is the NSIS script I used to create it.
I don't have time to maintain a full fledged installer with Clutter, GStreamer, VTE, GtkSource ecc... but if needed I can remove the ADG related stuff and leave a plain LGI-GTK installer. Just let me know.

[tumagonx]

Hi Just want to inform PyGI AIO also have LuaJIT+lgi https://sourceforge.net/projects/pygobjectwin32/files/ beside GJS/Seed (Javascript). I know it seems weird combo but it would otherwise waste of runtimes size to make another installer.

[ntd]

I just updated my cross-building toolchain to Lua 5.3.4 and lgi 0.9.1. I am happy to announce the GDK thread locking call is no more a problem.

[ousia]

@ntd, I think this issue is already solved, isn’t it?

Many thanks for your help.

[ntd]

@ntd, I think this issue is already solved, isn’t it?

@ousia I don't have the slightest idea: I'm still heavily using LGI but only on linux systems.

I close this though, just to avoid having an old issue hanging around forever.

[rolandlo]

For the record: lgi works on Windows (with Lua 5.4) and can be easily installed using MSYS2 and luarocks, see xournalpp/xournalpp#4522 (comment)