QUESTION: Re: Cross-platform GUI frameworks

[sydbarrett74]

If something like wxWidgets were compiled and linked as APE's, couldn't we also have graphical universal apps, as well? (I'm aware that wx is written in C++ rather than C.)

Seriously cool project!

[jart]

Glad you love the project. Sadly that's unlikely. APE assumes the build environment is hermetically sealed. wxWidgets works because it veneers dozens of system libraries, e.g. qt, x11, motif, webkit, cocoa, wine, sdl, libpng, libjpeg, libtiff, libxpm, libiconv, libmspack, gtkprint, gnomevfs, opengl, libnotify, etc. If you wanted it to work with APE then you'd need to also schlep in its full transitive closure of dependencies. My personal view is web apps are awesome at fully featured guis, terminals are awesome at being simple, and anything in-between is better left to the unsung heroes of the Linux community!

[pfalcon]

wxwindows and other qt's are clearly no-go, but without a kind of virtual framebuffer support this project is sadder than it could be.

[jart]

It's possible to call the WIN32 API directly if you want to special case your app on Windows to launch a GUI. Please see the Conway's Game of Life implementation I wrote this week, which demonstrates exactly that. The thing I recommend doing though is just using the Unix APIs since Cosmopolitan polyfills them across platforms, and it actually works reasonably well on Windows automatically, without having to do extra work. If you want a fancy GUI then my view is that nothing is better than a web app and Cosmopolitan offers excellent sockets support across platforms so you can host it via a command line distributable web server.

[Qix-]

nothing is better than a web app

I respect your opinion but that isn't what people who write C are doing, normally (writing a web server or something).

For a good first step, supporting simply SDL by itself would be a massive achievement. Does this come down to loading symbols dynamically?

[jart]

It's enormous in scope, I don't need it, and I wouldn't have the resources to do it if I did.

[Qix-]

You mean supporting platform dependent code, or supporting SDL? I wasn't suggesting you be the one to do so, I was merely pointing out that SDL would be a good next target (akin to the Lua interpreter and now the WASM runtime using Cosmopolitan).

I'm just curious how it could be solved now, without something added to APE.

[jart]

Cosmopolitan Libc has the "just works" on seven platforms because it statically links everything. We can't do that easily with something like SDL since we'd need to vendor all its dependencies for all platforms. Here's what that looks like on Linux alone:

$ ldd /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.9.0
        libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f6d97fbe000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6d97e3b000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6d97e36000)
        libpulse-simple.so.0 => /lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f6d97e2f000)
        libpulse.so.0 => /lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f6d97ddb000)
        libsndio.so.7.0 => /lib/x86_64-linux-gnu/libsndio.so.7.0 (0x00007f6d97dc9000)
        libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6d97c86000)
        libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f6d97a74000)
        libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f6d97a67000)
        libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f6d97a62000)
        libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007f6d97852000)
        libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f6d97647000)
        libXss.so.1 => /lib/x86_64-linux-gnu/libXss.so.1 (0x00007f6d97640000)
        libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f6d9743a000)
        libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f6d97435000)
        libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f6d97424000)
        libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f6d9741a000)
        libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f6d973d8000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6d973b5000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6d973ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d971ea000)
        libpulsecommon-12.2.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-12.2.so (0x00007f6d97164000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f6d9715c000)
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f6d97107000)
        libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6d970ed000)
        libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6d970c3000)
        libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f6d96eb9000)
        libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f6d96cb3000)
        libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x00007f6d96ca7000)
        libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f6d96ca2000)
        libICE.so.6 => /lib/x86_64-linux-gnu/libICE.so.6 (0x00007f6d96a85000)
        libSM.so.6 => /lib/x86_64-linux-gnu/libSM.so.6 (0x00007f6d96a7a000)
        libXtst.so.6 => /lib/x86_64-linux-gnu/libXtst.so.6 (0x00007f6d96874000)
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f6d967d3000)
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f6d967c5000)
        libsndfile.so.1 => /lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f6d96749000)
        libasyncns.so.0 => /lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f6d96543000)
        libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6d9633f000)
        libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6d96139000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6d9612e000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f6d96106000)
        liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f6d960e7000)
        libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f6d95fc9000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f6d95fb0000)
        libFLAC.so.8 => /lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f6d95d38000)
        libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x00007f6d95b2d000)
        libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f6d95aff000)
        libvorbisenc.so.2 => /lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f6d95a54000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6d95a3a000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f6d95a17000)

So we'd either need to vendor all those or do what everyone else already does, which is heuristically probe the system at runtime for preinstalled SDL libraries that can be dynamically linked. I'm not interested in doing what the conventional tools do, because that would mean we'd offer no value and no 10x improvements over the status quo.

I appreciate that you're interested in Cosmopolitan. I agree it would be nice. However I can not help you.