SDLUI - Bare bones GUI library made with SDL

Here's a small GUI library I've been working on for some time. It's meant to be used in SDL applications and its dependencies are standard SDL extensions (SDL_image, SDL_ttf). It's nowhere near finished but it's kind of usable. I won't be working on it for a while because of other life priorities, so if somebody finds it useful or wants to take over I'd be grateful.

Get it on Github


Edited by John on Reason: Initial post
Do you have a "real" application using that UI that we could test and look at the code ?

Edited by Simon Anciaux on
Simon, I was planning to do a level editor for a little game I'm working on, as a test for the UI code. But since the UI code isn't finished I haven't attempted to do so. The only thing that resembles an application is the included skeleton app in the repository, that draws a bunch of ui controls.

I've been caught up in doing my daughter's apartment renovation, so I've quit anything hobby related (like programming) for a while :p
I was hoping that someone who finds it useful could take over and improve/finish the thing!
You might not like the result after a handover
You would probably end up hating it if someone else took it over without supervision to tear it down and make something else. This is why Microsoft Windows keep deprecating everything that they didn't have time to document nor refactor. People even rewrite their own hobby projects from scratch if they forgot how to use them.

Many short breaks are good for development
A little time off a project while it's still small can help to improve documentation by giving you a beginner's perspective on what's too complex or unexpected when you come back. A long time of development followed by a sudden long stop without documentation usually kills projects permanently.

Like when writing a book, the beginning is always the easy part
90% of the total work is when the framework is almost complete and different users have different strong opinions on exactly how things should work by default. Fix one "bug" and you have broken a few other design principles along the way. The cost of refactoring also increases quadratically with the number of components depending on each other and breaking things in all directions. For that you need a clear vision for the project, or it will end up as a usability nightmare like the old versions of Blender.

Motivating people
If you just leave the project, anyone deciding to join would feel highly demotivated and unable to share a common sense of accomplishing a goal together, even if you hold daily pep talks and pay them full time salary. Their motivation is to program together, learn from others and increase their team skills.

Take your time, finish the project, promote it to users, and then you might be lucky enough to get bug reports for free. Anything else just doesn't feel realistic.
All valid points Dawoodoz and thanks for reminding them to me!
I tend not to finish my projects because I don't have the skills yet to manage anything bigger than this. It's a hobby of mine so when it becomes a little stressful I have the "life priorities" excuse :p Well I mean life priorities IS an issue, but I could certainly find a little time everyday for this. The greatest difficulty I have is that looking at my own code a couple of days later, it seems foreign to me.
Anyway, a couple of guys started making commits so at least I got a bit motivated.
If the code already looks foreign to you, writing documentation before coding might help to minimize public exposure across different modules.