This is a plea for advice - although it runs the risk of starting an opinion war. The plea needs setup.
I have been working on a CROSS PLATFORM educational app for about 10 years now and it was initially successfully completed in Java. To avoid the library installation problem, I was enticed to re-write it in D. This was successful except for the GUI portion. Major difficulties were the presence of TWO competing standard libraries, no obvious cross platform GUI (I'll discuss IUP in a bit), and I never really understood the (very sophisticated) type system. But I was able to create an MS Windows based GUI library in D to support the app.
The application was then re-written in GO - but I failed to research the GUI support adequately. I also discovered that my app was now LARGE and SLOW. A side trip was made to implement the GUI using a web browser. This worked but mostly only in Chromium - and would require the customer to adopt that browser.
Finally I discovered Nim and the non-GUI portion of the app has been successfully ported. IUP was initially used to create the IDE GUI portion of the app. Unfortunately a different layout scheme (other than HBox and VBox) was eventually required and I had no luck writing that layout scheme - which was like the Javascript <table> design.
I flirted with FLTK, but it's layout philosophy is "use our tool to design it" rather than IUP's (and Java's) philosophy: "let us size things for you".
So my GUI requirements are:
- Light Weight ( < 1Meg )
- No installation (static binding into app)
- Easily written layout managers (exposed API)
I have met these requirements in MS Windows - using the windows.nim module under a translated OO wrapper I wrote originally for D.
I was getting ready to learn enough GTK+ to adapt the wrapper to Linux. Then I saw multiple warnings about GTK+ notoriously breaking existing applications and some fuss about big vendors switching from GTK+3 back to GTK+2.
So my question (FINALLY) is:
Which Linux X11 toolkit would best suit my requirements?
Here are some that I looked at (and why I hesitate to use them):
- Qt (C++, too big, duplicates Nim OO, massive installation required)
- WxWidgets (C++, duplicates Nim OO, installation required)
- GTK+3 (Not Stable ???)
- GTK+2 (duplicates Nim OO, will support for it move to GTK+3 ???)
- FLTK (C++, nice and light - but no layout manager API)
- IUP (good - but no layout manager API)
- MOTIF (could not find any recent books (<$100.00) on it, some reports that it is dead, reportedly ugly???)
- XLIB (replaced by MOTIF, not supported now)
- X11 (reportedly hard to use - design your own widgets)
And a second question - where is a "rosetta stone" for translating MSWIN apps to LINUX?
Thanks for your patience.
GTK+3 (Not Stable ???)
I think not stable in not the correct term. There is no additional glue code like for Ruby, Python, Go and the others. So when it compiles and works, it is stable. And it compiles, and for my small examples it works, and I am confident that it would work for other applications. But as long no one is interested in really using it, I will not work on it, would not make much sense. Maybe when the delegates work, I will make the GC support. And some polishing -- but generally polished API's needs tutorials, while for the current plain wrapper C examples can be used.
GTK is definitely not a good choice for you and your users (if installing Java is already a problem).
We (METATEXX GmbH) are going to release our wxWidget bindings "soon". It needs a new Nim release to use it and some basic documentation about how to extend its features. This will be a manual port and is based on wxclib.
We can already package apps for Windows and OSX so that you do not have to install other stuff. But this is not (yet?) done with static linking but just by moving the needed DLLs or dylibs into the application directories.
Anyway... this also will not be the "perfect" GUI library for Nim. But it matches our goal to make native GUIs with Nim for the three desktop systems widely used and deliver a decent amount of functionally with an easy enough to use API for small and medium projects.
http://littlesvr.ca/grumble/2014/05/10/whos-screwing-up-gtk/
together with seeing other references to lack of backward compatibility in GTK. In contrast I wrote an MSWIN app that survived 10 years without revision (I had become afraid of changing it because I no longer really understood it well).
Perhaps the above url complaint was groundless - I lack the Linux experience to say.
And installation of GTK+2 is not a problem for my educational application because there would be three OS based versions of it anyway and the GUI basis would be whatever was most appropriate for the particular OS. I would like to use GUIs that operated at about the same level as the C language interface to MSWIN. It would be nice but not really necessary to use a common GUI framework for all the OS, since it would be wrapped in a Nim OO API in any case.
I do NOT want to burden my clients with the need to install so-s or dll-s and so would be interested in whether the suggested wxWidgets module could be statically linked in each of the three major OS.
Help me: I don't understand about the "burden" of having bundled libraries? That is perfectly normal for any application on OSX and Windows anyway? In OSX you do not even get an application icon if you do not use an app bundle. On windows this is what installers are for. On Linux people usually do NOT want stuff be bundled which is easily installed by the distribution.
I also do not see the need for a Nim OO wrapper on top of the GUI library. At least not widgets related. I would be happy to write everything just once and use the native OO abstraction of a mature GUI library above a wrapper which abstracts that to different GUI libraries (again). After all this was the reason to pick wxWidgets. It (mostly) works out of the box on all those systems.
BTW. I wrote wxPython Apps for WindowsNT which are still working in Windows 8.1 but also on OSX and Ubuntu. Actually I still use wxGlade on Windows XP to modify and make installers.
The app I am working on will allow the computer-challenged to create apps. Hence no complexity - installation is just ONE file, apps produced are just ONE file. I have no OSX experience at all - something new to learn. What was said about requiring "bundles" is alarming.
So, no "DLL Hell" - No "Oh dear, your program doesn't work anymore because your system upgraded the XYZ.dll to version PQR - so sorry!".
That is why Nim is so appealing - a Nim app works "out of the box" - no library installation necessary. Hence even when a new release of Nim comes out, the existing Nim binaries will still work. Of course, the Nim development environment has to be installed - but the clients will not be writing Nim apps.
BTW, is there an XCB "wrapper" anywhere. I haven't checked it out thoroughly, but XCB might solve my problem.
Have I misunderstood that a Nim wrapper can just be a file declaring the types and names of the resources in a C library and the Nim app just calls the library procs directly without any kind of adaptor code?
Though not technically a GUI library, have you thought about using something like SDL? If the GUI is simple enough, and you don't need a native look, you could use that. There's also some other nice graphics libraries such as Allegro.
Regarding what a Nim wrapper is, you are correct that they are usually just the types and functions exported by the C library. That being said, it's not always fun using basic wrappers like that, as you must write the Nim code in a C style, using typecasts and such. More advanced wrappers usually perform such trivial (or sometimes nontrivial) operations for you.
what about sciter?
it's cross-platform, lightweight (single dll: 3-5mb [1mb if you compress with upx]), uses html + tiscript(modified js) + css
but there are no nim bindings yet
there is a (c/cpp) api for embedding: https://github.com/c-smile/sciter-sdk
https://github.com/c-smile/sciter-sdk
I did not know about sciter - interesting. I had done an html/css gui for my app in go - but had some problems porting it to nim because of lack of "go-routines". I thought I would wait for the threading model to settle down some before trying again.
The downside was that only chrome/chromium had the command line support to remove the web decorations from the main window - so clients with some other browser would either suffer a bulky main window or have to install chrome - which would be at the upper level of their tolerance for "computer stuff". There was also some flicker when windows were resized - but maybe that was because of "go".
Sciter looked like a commercial product - a quick look did not show pricing?
Sciter's website says:
"Sciter is free if you use it in binary form as it is published on the site"
"You are on your own - so no warranties implied"
"FREE
stands for free usage of sciter32.dll/sciter64.dll (Windows), sciter-osx-64.dylib (OS X) and sciter-gtk-64.so (Linux) as they are published on the site in public SDK release. You are allowed to use them according to terms of license.htm included in public SDK distribution."
Thanks