It is also possible to position widgets on/outside the decoration area. I think a valid area needs to be calculated for display of widgets (x+borderSize+1,y+borderSize+1,w-borderSize-1,h-borderSize-1) - or preferably when the window displayed first - and this is then used to offset widget positions and detection.
Could also instead use it for a clipping area, although I dont prefer that as it could have a speed problem
Actually that wont work due to combo boxes 
Iâm actually seeing if it will - I need it really to be able to centre text
What problem is centering text? You add to the origin x of an area, half the width of that area, minus half the width of your text. Or i didnât understand the problem you have.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
The problem is that currently widgets are based on the screen position rather than the position of the window.
At the moment (although I have only tested one widget at the moment), it seems to be working - a widgetâs X & Y position also takes into account a windows X & Y position plus the windows decoration size, so that all widgets are inside a window and just cant appear everywhere.
It should work with lists fine as the text will e positioned inside a new window with up/down arrows based on the position of the initial wndow.
Yes these are simple calculations, all is much simpler when all coordinates are screen coordinates, that is SDL window coordinates. There are calculations, but these calculations are easy to understand, self-evident and need almost no explanation. Different from like, widget packing in GTK.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
With widget toolkits there is always that question, did i used the right one, or did i had to use another one. With kiss_sdl there might not be such question, as kiss_sdl is a generic, rudimentary way of creating graphical user interfaces in SDL. So it is almost like making it only in SDL, or if you made it only in SDL, and in a simple enough way, then it likely may not much differ. This is just to say again why kiss_sdl is not yet another widget toolkit. Or it is, but only what concerns the basic way of doing things, which is the same in almost all widget toolkits, but is mostly hidden.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
One thing that is a problem (but more to do with SDL2 events), is that holding down the mouse button for up/down/left/right slider buttons will only generate one event, so you have to keep tapping the buttonsâŚ
What is needed (later) is to record button status in the polling event and then KISS uses that.
MrTAToad wrote:
One thing that is a problem (but more to do with SDL2 events), is that holding down the mouse button for up/down/left/right slider buttons will only generate one event, so you have to keep tapping the buttonsâŚ
The event function of a scrollbar, progress bar and combo box has to be in the event loop and also in the main loop after the event loop with the event argument NULL. This generates pseudo âtime eventsâ. Because mouse clicking is not repeated by the operating system like a key press, so some âtime eventsâ are necessary for repeated clicking.
When doing it so, adding the scrollbar event function in two places, isnât the clicking on the arrows repeated then? I have never seen that happening, so when you did not forget to add the scrollbar event function second time with the event argument NULL, and the clicking is still not repeated, then you should write a bug report, writing the platform where you use it, and everything else that makes it possible to reproduce the bug.
It is the function kiss_getticks() in kiss_draw.c which provides the number of milliseconds since the initialization, that is used to generate the repeated âclick eventsâ. This function by default just calls the function SDL_GetTicks(). So when it really doesnât work, then likely SDL_GetTicks() doesnât work for some reason.
Why is it done in that way? First it is simple, and difficult to fail, as it only relies on getting the milliseconds, by default with SDL_GetTicks(). But second, calling an event function with the event argument NULL, is the general way of doing things. Like, one can generate some continuous animation of ones widgets, and activate it by calling the event function of that widget also with the event argument NULL. Thus generating effects which one cannot even easily dream about when using widget toolkits like GTK or Qt.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
Yes, I didnât have the routine in the two places.
The text part was somewhat similar - I suspect it was effectively polling twice.
Iâve modified the system a fair bit now (https://drive.google.com/file/d/0Bzff3iRdz9Jqd0F3RmJ0Vy1DSUE/view?usp=sharing) to get rid of the global variables and to add various extra things I will be needing for my game (which I should now be able to continue with).
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.
It is ok to modify, it is made for that.
There is by itself nothing wrong in global variables, it is important how they are used. Getting rid of global variables is the easiest way to avoid all the problems they may cause, but it is just a no-brainer to solve the problems. In kiss_sdl, global variables are supposed to be used as constants only, and changed only during the initiation. When one really does not like them, then it is ok to get rid of them, but i didnât do it because i didnât want to make the code more complex. One more argument to the functions, or one more member to the structures, all matters. Or if you have some other reason why you want to get rid of them, have several sets of settings or whatever, thatâs perfectly ok.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.
I donât understand what do you want to do.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
Iâm just going to chime in as a FRP sort of guy, I agree there are good
cases for globals when it comes to constants, but be weary when globals are
modified during the lifetime of the app. If you have some sort of state
attached to kiss_sdl that is completely localized, you may want something
like:
struct {
// Things that would normally be global go in here
SDL_Renderer *renderer;
} KISS_STATE;
KISS_STATE *kiss_init(...);From here, you have two options. One is you have a single swappable global
state, ie:
kiss_use_state(KISS_STATE *);
KISS_STATE *kiss_get_state(void);
KISS_STATE *kiss_copy_state();
// For any function that needs to use a global var, use kiss_get_state().
If you need to modify it, copy it, modify the copy, then kiss_use_state on
the copy.This will break all the examples, but itâs only a few lines to change. You
could have kiss_init still rendering an SDL_Renderer * and create a global
KISS_STATE in the background, for compatibility. Youâd have a separate
KISS_STATE *kiss_init_state() method that would eventually be the
migration path
Or you pass the KISS_STATE* into every function that needs access to the
global state. This is a much more painful refactor, but it has some
advantages with immutability. I could go on about the merits of this
approach, but the bottom line is that it is a very painful refactor, and
will break every example and every project using it.
But again, this is just opinion. The idea of your keeping it simple means
that what you currently have, along with globals, is probably the simplest,
so donât take what I wrote as heavy criticism or a need to refactor, just
thoughts.
On the brighter side, good job, this is a neat little ui kit to get a
simple app off the ground!On Mon, Jul 4, 2016 at 4:59 PM, actsl wrote:
It is ok to modify, it is made for that.
There is by itself nothing wrong in global variables, it is important how
they are used. Getting rid of global variables is the easiest way to avoid
all the problems they may cause, but it is just a no-brainer to solve the
problems. In kiss_sdl, global variables are supposed to be used as
constants only, and changed only during the initiation. When one really
does not like them, then it is ok to get rid of them, but i didnât do it
because i didnât want to make the code more complex. One more argument to
the functions, or one more member to the structures, all matters. Or if you
have some other reason why you want to get rid of them, have several sets
of settings or whatever, thatâs perfectly ok.
kiss_sdl - Simple universal GUI widget toolkit for SDL2
https://github.com/actsl/kiss_sdl
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
kiss_get_state() is to get a pointer to a global structure by function? Accessing by function enables to modify access, etc, but i donât think it is necessary in the default version, as global variables are used there just as simple constants. That is of course, a user should observe that, which is not that good, as some users may ignore that and change global variables, and then complain about unknown problems. It is a more flexible method, but it adds complexity. And the ultimate goal was that the default version were simple, so that new users can quickly start to use it, then change it when they learn more and need to do that.
I have also written an interpreter, where all was reentrant and thread-safe, no global variables of course. But there it was necessary, as one may want to embed the interpreter, and run multiple instances of it simultaneously. It was yet different for the interpreter though, as that interpreter had no global settings used everywhere. Widget toolkit is different in that respect, in that it has certain global settings that are used by all instances, or even threads that there may be.
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
actsl wrote:
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.
I donât understand what do you want to do.
The problem is that text can exceed the available size - all it needs is a clip rectable setup for the text entry box
actsl wrote:
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.
I donât understand what do you want to do.
The problem is that text can exceed the available size - all it needs is a clip rectable setup for the text entry box
MrTAToad wrote:
actsl wrote:
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.
I donât understand what do you want to do.
The problem is that text can exceed the available size - all it needs is a clip rectable setup for the text entry box
How can it be? The text selected from the text box of the combo box is clipped by the width of the entry box of the combo box (combobox->entry.textwidth) when copied to the entry box of the combo box, by the following, line 802 in the kiss_widgets.c of the kiss_sdl version 1.0.12, in the function kiss_combobox_event() .
kiss_string_copy(combobox->entry.text,
kiss_maxlength(kiss_textfont,
combobox->entry.textwidth,
(char *) kiss_array_data(combobox->textbox.array,
index), NULL),
(char *) kiss_array_data(combobox->textbox.array,
index), NULL);
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
Whoopsy - my fault. I was using a kiss_font structure that was defined, but not actually used, so the font advance was always 0âŚ