Kiss_sdl - Simple universal GUI widget toolkit for SDL

SDL Development
21

Two things i have to explain, after i just talked with someone in the #sdl channel.

  1. It is intentionally unfinished.

  2. The GUI does not look pretty by opinion of some, this is first because of the reason 1., the graphics is only primitive. But why was it drafted like this, it was on the principle that computer is an equivalent of a pen and paper. Not a machine or a control panel of a machine, like these who designed the Windows GUI likely thought. But pen and paper. We write on a white paper, with a pen of one color. Like we could write on a paper with flowers printed on it, but we donā€™t. Pen and paper are intentionally made simple, that nothing would distract us, when we read, what we wrote.

  3. It is not really skinnable, except that it is easy of course to change all images and fonts, and changing colors should also be simple. But it is rather made easy to change, so that you take it, and make out of it what you want to do.

And happy spring to everyone!

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

22

Version 0.10.2 is now in GitHub with some bug fixes https://github.com/actsl/kiss_sdl .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

23

Le 09/05/2016 07:01, actsl a ?crit :

Version 0.10.0 released GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2

UTF-8 support, structures for resources, a compiler macro for path to
resources. If you knew me, iā€™m very reluctant to change it.

Some things that I would like to understand:

  • The library is completely based on SDL, why donā€™t use the same naming
    convention ? Example Kiss_WindowDraw instead of kiss_window_draw,
  • It would be nice to have a real build system (like CMake).

Regarding the look and feel, wellā€¦ I think it needs some
reconsideration :-).

Kind regards,ā€“
David Demelier

24

markand wrote:

The library is completely based on SDL, why donā€™t use the same naming
convention ? Example Kiss_WindowDraw instead of kiss_window_draw

Because i donā€™t like the CaMel naming convention, and i think that it makes names difficult to read. If it would be more integrated to SDL2, i may change the naming convention.

It would be nice to have a real build system (like CMake).

I in general donā€™t like anything that needs and creates many rubbish files. Also i donā€™t like CMake that much, why not to have a simpler automake, with just some macros in the makefile, for appropriate paths, like a simple macro preprocessor. In that way, only makefile would be necessary, just like in the usual compiling with makefile only. But with that one may write in the makefile some general names of the libraries, etc, so makefile doesnā€™t have to be edited when installing new versions of the libraries or such. But as long as CMake is almost the only way to do that, at least what concerns Windows, then of course when one wants to use an automake, then CMake is often the only option

There was an issue created in the kiss_sdl project Segmentation Fault running Example1 from KISS_SDL 0.10.2 Ā· Issue #1 Ā· actsl/kiss_sdl Ā· GitHub , which was quickly solved and closed. It was caused by a mistake of the user, that he did not add a definition, to CMakeLists.txt , like add_definitions(-DRESDIR="ā€¦/ā€¦/src/") , that adds a macro definition to the compilerā€™s command line, that provides a relative path from the executable, to the resources (fonts and images, the path can also be absolute). He tried to compile the examples of my widget toolkit, in Macintosh. It built well, but running it resulted in a segmentation fault. It appeared that the only reason was that he put the executable into a different directory, but did not add the path to resources, as explained above, and the executable didnā€™t know where to load the resources. After he did that, it worked well.

So if you want an example of how to build this widget toolkit with CMake, then in the discussion of that issue there is provided the initial test project https://github.com/actsl/kiss_sdl/files/265266/Test_KISS.zip that only needs adding a definition for path of the resources in CMakeLists.txt , as said above, and it works. I also provided a test project there, but it was a simplistic case with the executable in the same directory as the source, just to test whether the issue was only in the missing path to resources, and it appeared to be.

Regarding the look and feel, wellā€¦ I think it needs some
reconsideration

I wrote about the general considerations of the look and feel, before in this thread. But one should consider that i did not try to make it into any finalized product, with a polished look and feel. This also would restrict one to use only a certain look and feel, which i think at least what concerns games, is not a good thing to do at all. And a possible looks and feels used in games, and why not also in applications, are very different. Therefore i provided only a simple initial, very generic look and feel, that can be changed into the look and feel that the user desires.

It is simple to change the look and feel. The easiest way is to replace the images for the elements of the widgets, there are only a few of them, and the fonts. It is also easy to change the colors of the widgets and also draw additional things on the widgets, like a graphical background, by overwriting the base drawing functions, the code of the widget toolkit doesnā€™t have to be changed at all for that. The code of the widget toolkit is made though easily changeable too, with everything abstracted away, so using different font libraries, image libraries, or even a different graphics library, may not be difficult at all.

Someone made a fork of it too, it looks like that he is going to use it as a widget toolkit on some 3D surface.

Now i think that i made all the changes necessary, and the code of the widget toolkit will not change any more. The version 0.10.4 of kiss_sdl is now in GitHub GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2 .

I hope you have fun using it.

kiss_sdl - Simple universal GUI widget toolkit for SDL2 GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2

25

The version 0.10.6 of kiss_sdl is now in GitHub with added support for building C++ projects https://github.com/actsl/kiss_sdl .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

26

The new version 0.10.8 of kiss_sdl is now in GitHub, with improved using with C++ https://github.com/actsl/kiss_sdl .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

27

If you want to build it with CMake, this is an example CMake project for it that i made https://github.com/actsl/kiss_sdl/files/283114/cmakekiss.zip , works for me in Linux. Others say that for making it to work in Macintosh, the 6. line in the CMakeLists.txt should be changed to the following.

Code:

set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
	"${Test_KISS_SOURCE_DIR}/cmake")

As of now, iā€™m not willing to change it to using CMake, as i want that the users can reliably build and compile it. With makefile, it now evidently builds and works faultlessly in Linux, Windows MinGW, Visual Studio and Macintosh, with both 64 bit and 32 bit operating systems. No one has knowingly tested it yet with Android or iOS, but it should work with these as well, that is, with almost anything that has a screen.

If you want to make it to dynamic library, change what needs to be changed in kiss_makefile , similar to that below. I wrote it in the way i know it should be done, i have tested that, but not with that makefile. You may only need a dynamic library, if you want to use kiss_sdl in a commercial product, and want that the library license will not extend to the product.

Code:

LDFLAGS = -lSDL2 -lSDL2_image -lSDL2_ttf -L. -lkiss_sdl
LIB = libkiss_sdl.so
all: $(LIB) $(EXE1) $(EXE2)
$(EXE1): kiss_example1.o
 	$(C) $^ $(LDFLAGS) -o $@
$(EXE2): kiss_example2.o
	$(C) $^ $(LDFLAGS) -o $@
$(LIB): kiss_widgets.o kiss_draw.o kiss_general.o kiss_posix.o
	$(C) -shared $^ $(LDFLAGS) -o $@

There are no issues, it is now beta tested by users, and it looks like that there is now no more need for any new releases or commits. So i think that it can now, as of the version 0.10.8 , declared to be stable. Iā€™m now waiting for screenshots from MrTAToad and others who said to try it, of using it in a game or application. This also may give an idea of how different the look can be, as i avoided to add to it any graphics gibberish, or anything else that is easy to make, so that it is not bloated.

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

28

I post this to announce that kiss_sdl now has become stable, there is the stable release 1.0.4 in GitHub now https://github.com/actsl/kiss_sdl .

I tested building a dynamic library, and it appears that it has to be like this below. The second lines in targets have to start with tabs, but posting code here replaces tabs with spaces. So write there tabs.

Code:

LDFLAGS = -lSDL2 -lSDL2_image -lSDL2_ttf -L. -lkiss_sdl
CFLAGS = -Wall -c -std=c89 -fPIC
LIB = libkiss_sdl.so
all: $(LIB) $(EXE1) $(EXE2)
$(EXE1): kiss_example1.o
	$(C) $^ $(LDFLAGS) -o $@
$(EXE2): kiss_example2.o
	$(C) $^ $(LDFLAGS) -o $@
$(LIB): kiss_widgets.o kiss_draw.o kiss_general.o kiss_posix.o
	$(C) -shared $^ -o $@

I donā€™t want to make any new commits or new releases in GitHub, and i hope that there will not be any, so that the users can rely on it remaining what it is. Some users are active though, and propose changes, some of which enable to diversify the GUI, without adding any complexity at all. Iā€™m all against unnecessary restrictions, but as it is KISS, then the most important is to keep it small and simple, as well as easily changeable.

I also added options to build in Macintosh in kiss_makefile. The only way how it now builds in Mac, is with CMake, and i found the locations where the SDL2 libraries are installed in Mac, from the CMake files from Mac. I have no Mac, so if someone has Mac, i would be thankful if one would test whether it builds with these options with makefile in Mac, or what possibly should be changed so that it will.

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

29

Makefile now works in Macintosh, in the new version 1.0.6 https://github.com/actsl/kiss_sdl .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

30

Busy implementing it in my game now (seriously upgrading my Assembloids game).

Have made a few changes, mainly because I will be eventually needing it converted back to SDL1 at some point in the future (due to using a system that only has SDL1).

Namely :

Returning constants instead of return 0;/return -1; for success/error
Removed SDL initialisation in kiss_init and SDL shutdown in kiss_clean (as my SDK will be initialised first). Although it wouldnā€™t make any difference, the code would just be taking up memory for no good reason.
Pass the SDL renderer to KISS and remove the parameters in functions, so using a private variable for SDL_Renderer
If a value of <=0 is passed for the screen width/height when initialising and/or window creation, then it will use the current screen size.
Add function to enable/disable window viability, rather than accessing structure variables directly.

31

MrTAToad wrote:

Removed SDL initialisation in kiss_init and SDL shutdown in kiss_clean (as my SDK will be initialised first).

Right, these should often be separate. I though want the default code to be as simple to use for beginners, as possible, so i donā€™t want to separate them in the default version. Iā€™m always in between keeping it easy to use for beginners, and making it more flexible for advanced users. The latter can be done by easy means, like it is easy to change it so that different resources (fonts and images) can be used in different widgets, but i always choose the former, as making starting to use it easy for beginners is so vital.

That one would change it, this is what it is thought to be, one can use it as is in the simple cases, and then change it in accordance with oneā€™s needs. A thing like that cannot be made simple otherwise.

Although it wouldnā€™t make any difference, the code would just be taking up memory for no good reason.

My system monitor didnā€™t show any significant increase of memory use when running the examples.

Valgrind tough showed a significant memory leak at exit, which was caused by a wrong order of destroying the resources. This is now fixed in the new release, version 1.0.8 GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2 .

Valgrind however, when testing kiss_example1, writes that at the end:

LEAK SUMMARY:
    definitely lost: 21,003 bytes in 474 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
    still reachable: 89,416 bytes in 551 blocks
         suppressed: 0 bytes in 0 blocks

At that, all was traced to SDL_Init(), SDL_CreateWindow(), SDL_CreateRenderer() and SDL_RenderClear(). To SDL_RenderClear() though only one time, and itā€™s always 63 bytes, no matter for how much to use the program, that is, no matter how many times to select things and do whatever in the user interface, itā€™s always only 63 bytes during the entire run of the program. I donā€™t know by now what is it caused by.

Pass the SDL renderer to KISS and remove the parameters in functions, so using a private variable for SDL_Renderer

Not a bad idea but, makes the _new function calls too long, and they are long already.

Add function to enable/disable window viability, rather than accessing structure variables directly.

To enable/disable window visibility? Not a bad idea but, i avoid everything that makes it anyhow more bloated.

Please post your screenshots when your game somewhat starts to run, itā€™s very important for people to get an idea of it, to see it used in a game or application. Your game does not have to work completely yet when posting these. And many thanks for the work you do. And to all others who are using it now, i know some who do. They all may realize the importance of the work all we do, for creating a simple alternative of GUI.

Fixed a memory leak at exit after testing with valgrind, in the new version 1.0.8 GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2 .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2

32

Could you think what can happen :wink: This was not the right way to fix it. The resources have to be freed in the opposite order than they are allocated.

Freeing resources in the opposite order than they are allocated, in the new version 1.0.10 https://github.com/actsl/kiss_sdl .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

33

Each text box, button etc could do with its own font.

In addition, text entry needs to deal with keyboard repeating - at the moment press a key and it thinks the key is being held down for a second or so.

34

image_new also needs a check to make sure a graphic is actually loadedā€¦[/code]

35

Do wish we could edit posts :slight_smile:

The same check is needed for font loading tooā€¦

36

I see you want to extend it, then do. But iā€™m not willing to have different images and fonts in different widgets in the default version, for the reasons i said in my previous posts. Except one can load ones own fonts and manually change the fonts of the label widgets to whatever fonts one wants. Which at all doesnā€™t mean that for some purposes extending it is not necessary or needed, no doubt it is. kiss_sdl is a kind of barebones, but it is barebones which can be used as such, and a complete GUI can be made with it as such. When something is barebones, then naturally one wants to add flesh to it, which is not difficult to do. One should understand my unwillingness to change it anyhow, but it may be difficult to see, as i changed it all the time.

It is that, talking about how to write a code for certain purposes, is easier to do. But it is more difficult for me, as it is not about coding only, but about all the principles of a general low level widget toolkit. What it should be and what it should not be, that is. And there are no easy solutions, what in coding are usually no-brainers. Iā€™m a programmer, but more than that iā€™m an innovator, i have a working experience in innovation, and innovation in software. And innovation has its ways of doing things.

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

37

Ah, it is indeed bad that one cannot edit the post here, though i also fully understand their mailing list needs.

You said keys donā€™t repeat? The operating system does repeating the keys. In what platform do you use it? Repeating the keys works well for me in Linux and Windows (Windows 7), i have not tested it by myself in Macintosh, but people did, and if there were so big problem as that, i think they did certainly say it. Maybe itā€™s about the settings of your operating system, normally keys should repeat.

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl

38

Oh yes, keys repeat - unfortunately every key press repeatsā€¦

39

MrTAToad wrote:

Oh yes, keys repeat - unfortunately every key press repeatsā€¦

Every time there is SDL_TEXTINPUT event, it receives event->text.text, which is the string of chars for one character. That is, it is always a string with length 1, if one uses only ascii characters, more if there is a unicode character.

If you receive a character twice, this means that there had to be two SDL_TEXTINPUT events for the same key press. I donā€™t know how this can happen. I have never seen that in any platforms. Then it should be something about the SDL or the operating system. There is nothing about setting it in the code of kiss_sdl, than SDL_StartTextInput(), once in kiss_init(). Fixing it in the rest of the code may not be possible, unless when one knows that every key press always causes two events.

Find out with some test code, whether your key presses always cause two SDL_TEXTINPUT events, and when this is the case, then this is a general problem, and should be talked somewhere separately, of how to fix it.

I donā€™t know of course what else may be wrong. It looks like adding an event function of an entry widget twice to the event loop or something. Anyway, by that what you say, i cannot reproduce it.

kiss_sdl - Simple universal GUI widget toolkit for SDL2 GitHub - actsl/kiss_sdl: Simple generic GUI widget toolkit for SDL2

40

But you are of course right that it should not go ahead when an image or a font cannot be loaded, this is my bad attention. It is fixed now, it prints a message to stderr when a resource cannot be loaded, frees the resources, and kiss_init() returns NULL.

So one more release :stuck_out_tongue:

kiss_init() now returns NULL at error, in the new version 1.0.12 https://github.com/actsl/kiss_sdl .

kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl