Little Forms – an open source minimalistic GUI widget library written in plain C
runtimelegend.com
runtimelegend.com
It works with NanoVG, so it is useful in environments where you're already running OpenGL.
Assuming this approach would relieve a lot of the stress I've experienced on my more popular projects. I'm seriously considering it.
I think one of the major advantages of open source is that you can fix a bug or add a feature that you want.
I have a variety of open source projects, and some fall towards each end of the spectrum.
Actually I think he himself just wants to not collaborate, but I don't see anything saying that you can't copy his code and then collaborate with others.
There are also other benefits of open source other than collaboration, such as security from being able to review the code, and being able to run in a totally free system.
(i just added the Win32 backend and the last time
i touched the code before that was at January 2011).
i wonder what sorts of projects he created it for
http://runtimelegend.com/rep/lforms/artifact/5c9b5b527c2b37e...
which was commited in july of 2011, so he was excusing a 6 month break from developing it
As someone who is Gtk, Qt, C++ averse, I thought I'll have to settle on something like FLTK. This is another option in my basket.
Is it tied to X or fairly independent? Because Wayland is an upcoming standard which aims to be a lot more cruft-free.
- It used to be that Qt was massive; because it existed before ubiquitous, usable STL implementations, Qt had to essentially also ship its own C++ standard library. Which meant that you couldn't use standard C++ strings, you had to use QString, and so on. This is less true with Qt 4 & 5, but reputations stick around.
- Often-times C++ APIs are a pain, even if you are using C++, many people have the opinion that the API exposed should be C.
And the STL data structures are sometimes kind of unwieldy:
if (dict.find(key) != dict.end()) { ... }
if (dict.contains(key)) { ... }
// std::vector has no sort function, haha!
std::sort(std_vector.begin(), std_vector.end());
// std::sort doesn't work on std::list, haha!
std_list.sort();
for (unsigned int idx = 0; idx < v.size(); ++idx) {...}
Even being conservative, say you had a struct of size 24 bytes (e.g. 3 doubles x, y and z) then now you're up to 48G.
So yes, there are very few situations where you'll have meaningful data that would fill a vector indexed by signed ints without running out of memory first.
Can you imagine how stupid it would feel if you had to abandon all your std::vector-using code the moment you need to deal with an array bigger than 2 billion elements?
If you have 2 billion 2 byte elements then that's 4gb which is the total addressable space on a 32-bit system - leaving no room for program code or any other data meaning you couldn't run anything.
You could go 64bit, but then signed ints go up to (2^63)-1 and you have the same problem - elements more than a single byte in size will cause you to run out of addressable memory before you exhaust available signed ints.
Compared to the majority of other uses of std::vector which will never be able to overflow signed ints.
I get from a logical point of view that size() would never be < 0 therefore it makes sense to use an unsigned int, however from a practical point of view it also makes programs more susceptible to a number of pernicious bugs that can catch out unsuspecting programmers, e.g. things like
for ( size_t i = v.size(); i >= 0; --i )
{
...
}
I agree, STL has done the "right" thing with sizes; of course negative sizes are meaningless. The problem is, Qt's way is so much nicer to use, even though it is obviously "wrong." Type three characters, done. Putting "int" in your headers, it's obvious what's going on--you're getting a number back. I suppose std::size_t is obvious, but it's hard to read, and I hate typing underscores. Again, more correct, but I hate doing it, which is just another reason why Qt is such fun to use compare to STL.
std::list's iterator type: http://en.cppreference.com/w/cpp/container/list
std::sort's iterator requirements: http://en.cppreference.com/w/cpp/algorithm/sort
All the different types of iterator: http://en.cppreference.com/w/cpp/iterator
(This might seem like needless nitpicking to some; to me, it's more like knowing why you can't, say, seek on a socket.)
The moc is to effectively extend C++ with signals and slot at a language level. I'm not crazy about the moc, but I love signals and slots. The only alternative is slow-compiling templates like boost signals and slots, which also have less than compelling syntax.
- I'm in the camp that thinks widget libraries for C++ should be workable in C.
- I'm big on minimalism, and being strongly aware of "90% of programs out there are bloated", and was horrified when I had to install a tiny Qt based program in ubuntu, and it required me to install a gazillion packages that looked like they belonged to Qt. (I don't remember the details).
- I always keep looking for C programs that can do in a couple thousand lines, what takes tens of thousands of non-C code for other programs to accomplish. I'm fairly aligned with the suckless philosophy, although I may not 100% agree with them. (suckless website would give you a good idea of what I'm talking about).
- Internationalization: The edit control doesn't support input method editors. On Windows, wide-character functions aren't used; that means Unicode isn't supported.
- Accessibility: Here I'm talking about the ability for users with disabilities, most notably blind users but also users with mobility impairments, to access a UI via assistive technologies such as screen readers or alternative types of input. This requires the GUI toolkit to implement an accessibility API such as Microsoft Active Accessibility or UI Automation on Windows, or AT-SPI for X11-based environments. This is something that practically everyone who sets out to implement a lean, mean, simple toolkit just doesn't pay attention to.
- Native look: The toolkit doesn't attempt to mimic the look of the rest of the system at all. On my Windows 10 machine, the demo looks like a throwback to Windows 95. This is also an accessibility issue, for low-vision users that need a different color scheme.
And there are probably other considerations I've forgotten or am unaware of. You'd probably be better off using one of those big, bloated C++ toolkits, like Qt or (better yet, IMO) wxWidgets. Not GTK, since that doesn't cover accessibility except under X11 via GNOME.
On the other hand... I kind of want vector graphics, and cairo would be really great for that, and if I use cairo, well I might as well use gtk, and... hmm. I see why these things end up with lots of features.