3 ms·

If it's always the worst that's getting all the indie dev attention there's probably something to it that you're ignoring or prioritizing lower than the people

by jdiff 3y ago

If it's always the worst that's getting all the indie dev attention there's probably something to it that you're ignoring or prioritizing lower than the people putting in the legwork.

badsectoracula 3y ago
There aren't really that many GUI toolkits in C[0] (which is what makes it easy to make bindings to other languages) - it is pretty much Gtk and... Motif. Ok, XForms too, probably. Toolkits in other languages need some C intermediate - e.g. Lazarus has a Qt backend for LCL and since Free Pascal can only use the C ABI there is a "qt5pas" library written in C++ that exposes a C API that programs must link against. This can be annoying. [0] ignoring Win32 as that is Windows-specific... unless you consider writing against libwine but i don't think anything uses that as a toolkit
- seabass-labrax 3y ago
  Your [0] is actually a pretty neat idea - Wine is small and well-supported, and kind of cross-platform by definition. Even better if you explicitly ensured compatibility with both Linux and Windows, for instance with CI testing every build for API errors. After all, GTK kind of has a Wine-style compatibility layer when running on Windows; it's just often statically linked into the binary rather than installed separately.
  - badsectoracula 3y ago
    Winelib (not libwine, my bad) isn't really that great for non-Windows stuff, it is really meant for porting applications that use Windows API calls and it really takes over everything. For example you need to compile the program using "winegcc", which creates a shell script that calls Wine to load the application (the application is compiled as a .so so it can use Linux libraries and calls, it isn't a Windows program). This in turn loads the full Wine server with its various services and Windows compatibility layers. And chances are you'll need to use "winemaker" to build the code (it generates a Makefile for you). Just as a test, compiling and running a very simple "hello, world" program that calls MessageBoxA to show a message box and exits still loads a bunch of processes (checked via ps -A) and dumps a bunch of diagnostics to the terminal. Also, IMO while Wine's GUI bits generally work, they do have a lack of polish even compared to their Windows 95 counterparts.

by jdiff 3y ago

If it's always the worst that's getting all the indie dev attention there's probably something to it that you're ignoring or prioritizing lower than the people putting in the legwork.

badsectoracula 3y ago

There aren't really that many GUI toolkits in C[0] (which is what makes it easy to make bindings to other languages) - it is pretty much Gtk and... Motif. Ok, XForms too, probably. Toolkits in other languages need some C intermediate - e.g. Lazarus has a Qt backend for LCL and since Free Pascal can only use the C ABI there is a "qt5pas" library written in C++ that exposes a C API that programs must link against. This can be annoying. [0] ignoring Win32 as that is Windows-specific... unless you consider writing against libwine but i don't think anything uses that as a toolkit

seabass-labrax 3y ago
Your [0] is actually a pretty neat idea - Wine is small and well-supported, and kind of cross-platform by definition. Even better if you explicitly ensured compatibility with both Linux and Windows, for instance with CI testing every build for API errors. After all, GTK kind of has a Wine-style compatibility layer when running on Windows; it's just often statically linked into the binary rather than installed separately.
- badsectoracula 3y ago
  Winelib (not libwine, my bad) isn't really that great for non-Windows stuff, it is really meant for porting applications that use Windows API calls and it really takes over everything. For example you need to compile the program using "winegcc", which creates a shell script that calls Wine to load the application (the application is compiled as a .so so it can use Linux libraries and calls, it isn't a Windows program). This in turn loads the full Wine server with its various services and Windows compatibility layers. And chances are you'll need to use "winemaker" to build the code (it generates a Makefile for you). Just as a test, compiling and running a very simple "hello, world" program that calls MessageBoxA to show a message box and exits still loads a bunch of processes (checked via ps -A) and dumps a bunch of diagnostics to the terminal. Also, IMO while Wine's GUI bits generally work, they do have a lack of polish even compared to their Windows 95 counterparts.