Hello everyone.
Over the past week I’ve been working on a widget-based GUI library to be
used together with SDL, called Killer Widgets 1. That is, it expects SDL
types on its API and uses them internally. It is also written in C89. Its
goal is to provide means to create GUIs mainly to be used in game
interfaces (like those on the good-old-days RPGs for SNES), thus it is not
meant to have a very large set of widgets. I tried to make the library as
less intrusive as possible. It receives events via SDL_AddEventWatch thus
not changing your event loop. The only thing it needs is a KW_Paint call in
every frame.
The library is tileset based, a tile is used to draw each corner and edge
and fill its area, so its easy to swap the style of your widgets (you can
use a different tileset for each widget). Relevant events (mouse over,
mouse down, keypress, etc) are reported via callbacks.
Wdgets that are in a usable state right now are the frame, label, editbox
and button. You can extend and create your new widget types easily as the
library was designed to be extensible. Each already provided widget uses
only the KiWi public API 2.
I’d like to hear from you any feedback that you might have about it and
also suggestions on which type of widget or feature you might find useful
when implementing a GUI for your games. I’d also welcome any help if you
are interested. You can access the planned features/roadmap at 3.
Thanks!
– Leonardo.
Sound really cool, are there any plans to support SDL_ttf style menus,
buttons ?On Fri, May 9, 2014 at 2:52 PM, Leonardo Guilherme < leonardo.guilherme at gmail.com> wrote:
Hello everyone.
Over the past week I’ve been working on a widget-based GUI library to be
used together with SDL, called Killer Widgets 1. That is, it expects SDL
types on its API and uses them internally. It is also written in C89. Its
goal is to provide means to create GUIs mainly to be used in game
interfaces (like those on the good-old-days RPGs for SNES), thus it is not
meant to have a very large set of widgets. I tried to make the library as
less intrusive as possible. It receives events via SDL_AddEventWatch thus
not changing your event loop. The only thing it needs is a KW_Paint call in
every frame.
The library is tileset based, a tile is used to draw each corner and edge
and fill its area, so its easy to swap the style of your widgets (you can
use a different tileset for each widget). Relevant events (mouse over,
mouse down, keypress, etc) are reported via callbacks.
Wdgets that are in a usable state right now are the frame, label, editbox
and button. You can extend and create your new widget types easily as the
library was designed to be extensible. Each already provided widget uses
only the KiWi public API 2.
I’d like to hear from you any feedback that you might have about it and
also suggestions on which type of widget or feature you might find useful
when implementing a GUI for your games. I’d also welcome any help if you
are interested. You can access the planned features/roadmap at 3.
Thanks!
– Leonardo.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Demos. ShowCases, Shots !!! Now !!! 
Hi Leonardo,
This definitely looks interesting! However, a brief look shows me that
it uses the BSD license which is not fully compatible with the
Zlib/Libpng license used by the rest of SDL. As a potential user this
would present a problem for me - primarily due to the fact that the
Zlib/Libpng license requests attribution in binaries where as the BSD
license enforces it. Would you consider changing the license to be the
same as the one used by SDL 2?
Kind regards,
Philip BennefallOn 2014-05-09 15:52, Leonardo Guilherme wrote:
Hello everyone.
Over the past week I’ve been working on a widget-based GUI library to
be used together with SDL, called Killer Widgets 1. That is, it
expects SDL types on its API and uses them internally. It is also
written in C89. Its goal is to provide means to create GUIs mainly to
be used in game interfaces (like those on the good-old-days RPGs for
SNES), thus it is not meant to have a very large set of widgets. I
tried to make the library as less intrusive as possible. It receives
events via SDL_AddEventWatch thus not changing your event loop. The
only thing it needs is a KW_Paint call in every frame.
The library is tileset based, a tile is used to draw each corner and
edge and fill its area, so its easy to swap the style of your widgets
(you can use a different tileset for each widget). Relevant events
(mouse over, mouse down, keypress, etc) are reported via callbacks.
Wdgets that are in a usable state right now are the frame, label,
editbox and button. You can extend and create your new widget types
easily as the library was designed to be extensible. Each already
provided widget uses only the KiWi public API 2.
I’d like to hear from you any feedback that you might have about it
and also suggestions on which type of widget or feature you might find
useful when implementing a GUI for your games. I’d also welcome any
help if you are interested. You can access the planned
features/roadmap at 3.
Thanks!
– Leonardo.
2014-05-09 11:14 GMT-03:00 Alexander Chaliovski :
Sound really cool, are there any plans to support SDL_ttf style menus,
buttons ?
What do you mean by SDL_ttf style menus?
There are plans to support drop-down menus, yes. Actually it reminds me to
put those on the roadmap, heh.
2014-05-09 11:24 GMT-03:00 Juan Manuel Borges Ca?o :
Demos. ShowCases, Shots !!! Now !!! 
They are all in the repository: GitHub - mobius3/kiwi: KiWi: Killer Widgets
There are three screenshots you can see, clicking on them leads to their
code. I’m adding a fourth soon.
2014-05-09 12:15 GMT-03:00 Philip Bennefall :
Hi Leonardo,
This definitely looks interesting! However, a brief look shows me that it
uses the BSD license which is not fully compatible with the Zlib/Libpng
license used by the rest of SDL. As a potential user this would present a
problem for me - primarily due to the fact that the Zlib/Libpng license
requests attribution in binaries where as the BSD license enforces it.
Would you consider changing the license to be the same as the one used by
SDL 2?
Yes, I can change it to zlib. I choose BSD of lazyness because github would
already provide a LICENSE file for me
Just to let you know, KiWi is now zlib licensed.
2014-05-09 13:46 GMT-03:00 Leonardo Guilherme <@Leonardo_Guilherme>
:>
2014-05-09 11:14 GMT-03:00 Alexander Chaliovski :
Sound really cool, are there any plans to support SDL_ttf style menus,
buttons ?
What do you mean by SDL_ttf style menus?
There are plans to support drop-down menus, yes. Actually it reminds me to
put those on the roadmap, heh.
2014-05-09 11:24 GMT-03:00 Juan Manuel Borges Ca?o <juanmabcmail at gmail.com
:
Demos. ShowCases, Shots !!! Now !!!
They are all in the repository: GitHub - mobius3/kiwi: KiWi: Killer Widgets
There are three screenshots you can see, clicking on them leads to their
code. I’m adding a fourth soon.
2014-05-09 12:15 GMT-03:00 Philip Bennefall :
Hi Leonardo,
This definitely looks interesting! However, a brief look shows me that it
uses the BSD license which is not fully compatible with the Zlib/Libpng
license used by the rest of SDL. As a potential user this would present a
problem for me - primarily due to the fact that the Zlib/Libpng license
requests attribution in binaries where as the BSD license enforces it.
Would you consider changing the license to be the same as the one used by
SDL 2?
Yes, I can change it to zlib. I choose BSD of lazyness because github
would already provide a LICENSE file for me
Leonardo,
When compiling with gcc, you should use -std=c89 -pedantic-errors in your
CFLAGS to and when using MSVC use /Za in your CFLAGS to ensure that
compiler specific extensions are disabled and it that it really is C89
compatible. (I just did a quick skim so if you have these already good deal)
Cheers,
JonathanOn Fri, May 9, 2014 at 3:43 PM, Leonardo Guilherme < leonardo.guilherme at gmail.com> wrote:
Just to let you know, KiWi is now zlib licensed.
2014-05-09 13:46 GMT-03:00 Leonardo Guilherme <
leonardo.guilherme at gmail.com>:
2014-05-09 11:14 GMT-03:00 Alexander Chaliovski :
Sound really cool, are there any plans to support SDL_ttf style menus,
buttons ?
What do you mean by SDL_ttf style menus?
There are plans to support drop-down menus, yes. Actually it reminds me
to put those on the roadmap, heh.
2014-05-09 11:24 GMT-03:00 Juan Manuel Borges Ca?o <
juanmabcmail at gmail.com>:
Demos. ShowCases, Shots !!! Now !!!
They are all in the repository: GitHub - mobius3/kiwi: KiWi: Killer Widgets
There are three screenshots you can see, clicking on them leads to their
code. I’m adding a fourth soon.
2014-05-09 12:15 GMT-03:00 Philip Bennefall :
Hi Leonardo,
This definitely looks interesting! However, a brief look shows me that
it uses the BSD license which is not fully compatible with the Zlib/Libpng
license used by the rest of SDL. As a potential user this would present a
problem for me - primarily due to the fact that the Zlib/Libpng license
requests attribution in binaries where as the BSD license enforces it.
Would you consider changing the license to be the same as the one used by
SDL 2?
Yes, I can change it to zlib. I choose BSD of lazyness because github
would already provide a LICENSE file for me
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-05-09 22:41 GMT-03:00 Jonathan Greig :
Leonardo,
When compiling with gcc, you should use -std=c89 -pedantic-errors in your
CFLAGS to and when using MSVC use /Za in your CFLAGS to ensure that
compiler specific extensions are disabled and it that it really is C89
compatible. (I just did a quick skim so if you have these already good deal)
Thanks Jonathan. Turns out that I was using a lot of // comments and
putting variable declarations mixed with code. These are all fixed now.
Isn’t the only relevant compiler that doesn’t support C99 MSVC?
And even they support // comments and variable declarations within the code.
So I personally wouldn’t worry about “real” C89 compatibility… it’s
2014 after all.
Cheers,
DanielAm 10.05.2014 13:16, schrieb Leonardo Guilherme:
2014-05-09 22:41 GMT-03:00 Jonathan Greig <redteam316 at gmail.com
<mailto:redteam316 at gmail.com>>:
Leonardo,
When compiling with gcc, you should use -std=c89 -pedantic-errors in
your CFLAGS to and when using MSVC use /Za in your CFLAGS to ensure
that compiler specific extensions are disabled and it that it really
is C89 compatible. (I just did a quick skim so if you have these
already good deal)
Thanks Jonathan. Turns out that I was using a lot of // comments and
putting variable declarations mixed with code. These are all fixed now.
2014-05-09 22:41 GMT-03:00 Jonathan Greig <redteam316 at gmail.com
<mailto:redteam316 at gmail.com>>:
Leonardo,
When compiling with gcc, you should use -std=c89 -pedantic-errors in
your CFLAGS to and when using MSVC use /Za in your CFLAGS to ensure
that compiler specific extensions are disabled and it that it really
is C89 compatible. (I just did a quick skim so if you have these
already good deal)
Thanks Jonathan. Turns out that I was using a lot of // comments and
putting variable declarations mixed with code. These are all fixed now.
Isn’t the only relevant compiler that doesn’t support C99 MSVC?
And even they support // comments and variable declarations within the code.
So I personally wouldn’t worry about “real” C89 compatibility… it’s
2014 after all.
Cheers,
Daniel
I actually ran into issues with MSVC only yesterday where I was writing
some C code and the compiler was giving me no end of trouble because I
had variable declarations mixed with code. So at least in its default
release configuration, MSVC certainly doesn’t accept it. I’m guessing
there is some flag you can set, but in my view the default settings
should work if at all possible - no special switches should be
necessary. So I think C89 compatibility still has some relevance.
Kind regards,
Philip BennefallOn 2014-05-10 13:33, Daniel Gibson wrote:
Am 10.05.2014 13:16, schrieb Leonardo Guilherme:
When concerning C code that is meant to be portable, those flags save major
porting headaches and you will have less bug reports as a result.On Sat, May 10, 2014 at 6:33 AM, Daniel Gibson wrote:
Am 10.05.2014 13:16, schrieb Leonardo Guilherme:
2014-05-09 22:41 GMT-03:00 Jonathan Greig <@Jonathan_Greig
mailto:Jonathan_Greig>:
Leonardo,
When compiling with gcc, you should use -std=c89 -pedantic-errors in
your CFLAGS to and when using MSVC use /Za in your CFLAGS to ensure
that compiler specific extensions are disabled and it that it really
is C89 compatible. (I just did a quick skim so if you have these
already good deal)
Thanks Jonathan. Turns out that I was using a lot of // comments and
putting variable declarations mixed with code. These are all fixed now.
Isn’t the only relevant compiler that doesn’t support C99 MSVC?
And even they support // comments and variable declarations within the
code.
So I personally wouldn’t worry about “real” C89 compatibility… it’s 2014
after all.
Cheers,
Daniel
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hi Leonardo,
This is offlist because I don’t have any thing of real value to add to
the discussion at the moment. I just wanted to say I really like the
idea of your project and I look forward to trying it in the future.
Right now I’m trying to get a new engine off the ground so I’m not yet
looking at widgets.
Quick thoughts:
-
I love that you are doing pure C (instead of C++). I spend a lot of
time with language bindings, e.g. Lua, JavaScript, and C is the best
language for binding and portability.
-
On the language binding stuff, callbacks are always the hardest
thing to bind. If you keep that in the back of your mind, I would
appreciate it
-
I spend a lot of time on mobile. The two most difficult things are:
-
Text entry fields (because they require native keyboard API
integration on iOS/Android)
-
Table views: This is probably the hardest widget to make, but it is
also kind of the most desirable on mobile.
-
Also remember that things like mouse over are meaningless on mobile
Anyway, keep up the great work.
Thanks,
EricOn 5/9/14, Leonardo Guilherme <leonardo.guilherme at gmail.com> wrote:
Hello everyone.
Over the past week I’ve been working on a widget-based GUI library to be
used together with SDL, called Killer Widgets 1. That is, it expects SDL
types on its API and uses them internally. It is also written in C89. Its
goal is to provide means to create GUIs mainly to be used in game
interfaces (like those on the good-old-days RPGs for SNES), thus it is not
meant to have a very large set of widgets. I tried to make the library as
less intrusive as possible. It receives events via SDL_AddEventWatch thus
not changing your event loop. The only thing it needs is a KW_Paint call in
every frame.
The library is tileset based, a tile is used to draw each corner and edge
and fill its area, so its easy to swap the style of your widgets (you can
use a different tileset for each widget). Relevant events (mouse over,
mouse down, keypress, etc) are reported via callbacks.
Wdgets that are in a usable state right now are the frame, label, editbox
and button. You can extend and create your new widget types easily as the
library was designed to be extensible. Each already provided widget uses
only the KiWi public API 2.
I’d like to hear from you any feedback that you might have about it and
also suggestions on which type of widget or feature you might find useful
when implementing a GUI for your games. I’d also welcome any help if you
are interested. You can access the planned features/roadmap at 3.
Thanks!
– Leonardo.
–
Beginning iPhone Games Development
Apologies. Meant the above message to be offlist. Oh well, nothing
really private or embarrassing was said 
Thanks,
EricOn 5/15/14, Eric Wing <@Eric_Wing> wrote:
On 5/9/14, Leonardo Guilherme <leonardo.guilherme at gmail.com> wrote:
Hello everyone.
Over the past week I’ve been working on a widget-based GUI library to be
used together with SDL, called Killer Widgets 1. That is, it expects
SDL
types on its API and uses them internally. It is also written in C89. Its
goal is to provide means to create GUIs mainly to be used in game
interfaces (like those on the good-old-days RPGs for SNES), thus it is
not
meant to have a very large set of widgets. I tried to make the library as
less intrusive as possible. It receives events via SDL_AddEventWatch thus
not changing your event loop. The only thing it needs is a KW_Paint call
in
every frame.
The library is tileset based, a tile is used to draw each corner and edge
and fill its area, so its easy to swap the style of your widgets (you can
use a different tileset for each widget). Relevant events (mouse over,
mouse down, keypress, etc) are reported via callbacks.
Wdgets that are in a usable state right now are the frame, label, editbox
and button. You can extend and create your new widget types easily as the
library was designed to be extensible. Each already provided widget uses
only the KiWi public API 2.
I’d like to hear from you any feedback that you might have about it and
also suggestions on which type of widget or feature you might find useful
when implementing a GUI for your games. I’d also welcome any help if you
are interested. You can access the planned features/roadmap at 3.
Thanks!
– Leonardo.
Hi Leonardo,
This is offlist because I don’t have any thing of real value to add to
the discussion at the moment. I just wanted to say I really like the
idea of your project and I look forward to trying it in the future.
Right now I’m trying to get a new engine off the ground so I’m not yet
looking at widgets.
Quick thoughts:
-
I love that you are doing pure C (instead of C++). I spend a lot of
time with language bindings, e.g. Lua, JavaScript, and C is the best
language for binding and portability.
-
On the language binding stuff, callbacks are always the hardest
thing to bind. If you keep that in the back of your mind, I would
appreciate it
-
I spend a lot of time on mobile. The two most difficult things are:
-
Text entry fields (because they require native keyboard API
integration on iOS/Android)
-
Table views: This is probably the hardest widget to make, but it is
also kind of the most desirable on mobile.
-
Also remember that things like mouse over are meaningless on mobile
Anyway, keep up the great work.
Thanks,
Eric
–
Beginning iPhone Games Development
Learn how to program games for iOS
–
Beginning iPhone Games Development
- On the language binding stuff, callbacks are always the hardest
thing to bind. If you keep that in the back of your mind, I would
appreciate it
Welp, I think I already went a lot on the wrong lane already then. All
events (clicks, mouse over, etc) are handled via callbacks. I don’t really
know how else I’d do this. Maybe have a polling function? Yeah, that can
work, something like SDL_GetKeyState would return you the state of the
pressed keys regardless if you handled those events or not. Maybe something
like KW_IsMouseOver(widget). What do you think?
- I spend a lot of time on mobile. The two most difficult things are:
- Text entry fields (because they require native keyboard API
integration on iOS/Android)
Yeah, indeed. Actually I’m struggling with making Android’s swype work
properly (i.e, handling SDL_TEXTEDIT events properly) in my editbox widget.
Spent more time in it than in the whole library already.
- Table views: This is probably the hardest widget to make, but it is
also kind of the most desirable on mobile.
I intend to address this in a grid layout thing, like Qt’s layout. I just
have to figure if its better to make layouts a widget per se or just a
geometry manager.
- Also remember that things like mouse over are meaningless on mobile
True, I still have to decide whether I’ll block the event or not.
Contrary to what you think, this thread is surely the place for
contributions such as this kind of feedback. Thanks for them.
- On the language binding stuff, callbacks are always the hardest
thing to bind. If you keep that in the back of your mind, I would
appreciate it
Welp, I think I already went a lot on the wrong lane already then. All
events (clicks, mouse over, etc) are handled via callbacks. I don’t really
know how else I’d do this. Maybe have a polling function? Yeah, that can
work, something like SDL_GetKeyState would return you the state of the
pressed keys regardless if you handled those events or not. Maybe something
like KW_IsMouseOver(widget). What do you think?
I rather like SDL’s way of handling it with events. If your GUI is
SDL-specific, you might just drop events into SDL’s event queue.
- Also remember that things like mouse over are meaningless on mobile
True, I still have to decide whether I’ll block the event or not.
Contrary to what you think, this thread is surely the place for
contributions such as this kind of feedback. Thanks for them.
I’d include it, just with the warning that it’s not useful on mobile
devices.
JosephOn Sat, May 17, 2014 at 12:19:41PM -0300, Leonardo Guilherme wrote: