Attributes
On the first reading, you should assume something like
All of that, even the callbacks, is achieved through the use of attributes.
Without looking at the C source, I would hazard that all attributes are in fact stored as pointers, or more accurately machine-sized words, which delivers high performance, with a handful of selected routines carefully taking a copy of any volatile strings, floats, etc and keeping them safe for the duration. My first reaction was predictable enough given my obsession with performance, but once I accepted it is no big deal to convert "200" to 200, or "YES/NO" to 1/0, I realised it is a pretty good way to keep things simple.
The majority of attributes are implemented using text strings, but there are also routines for storing (and perhaps more importantly retrieving) numbers, pointers, etc. Depending on the interface element, some attributes are inheritable (for instance the BGCOLOR on an IupButton: if not specifically set, a button takes on the background colour of whatever control it is sitting on), and some attributes are non-inheritable (eg TITLE). Some must be set at creation time, ie before the dialog is first displayed (eg CANFOCUS), while others can be amended on the fly (eg ACTIVE), and some are read-only, or platform-specific. Whilst most attributes are static, referred to as needed, a few trigger actions when read or set (eg KEY). These are all documented for each element type.
You can also set bespoke application-specific attributes on any control, which the underlying platform-specific driver will completely ignore. The most likely thing I can think of where that might be useful would be to have a single callback that deals with several controls, which fetches an attribute off the control that triggered it, and tweaks the behaviour accordingly. Perhaps (I have not tried this) a clock application could have a single callback that gets called by three timers, and draws the hour, minute, and second hand appropriately, but I digress...
The point I am trying to make here is that, sheer number of different controls aside, by and large the core of IUP is jaw-droppingly trivial - all the important stuff gets controlled by attributes. Equally there are quite a few ways to set and retrieve attributes, of which there are plenty knocking about, but otherwise the attribute system itself is also conceptually quite trivial.
button = IupButton("button") and without worrying too much about the
technical details of that, it should be obvious that it creates a button. Equally I am sure you can imagine a fairly long list of things
you might want to alter: size, font, colour, dynamically change the text, add an image, enable/disable it, and of course configure what
happens when it is clicked.
Aside: in IUP element position is dynamically determined through nested containers and fillers, though if you are adamantly married to
specifying everything in pixels you could always try using an IupCbox.
All of that, even the callbacks, is achieved through the use of attributes.
Without looking at the C source, I would hazard that all attributes are in fact stored as pointers, or more accurately machine-sized words, which delivers high performance, with a handful of selected routines carefully taking a copy of any volatile strings, floats, etc and keeping them safe for the duration. My first reaction was predictable enough given my obsession with performance, but once I accepted it is no big deal to convert "200" to 200, or "YES/NO" to 1/0, I realised it is a pretty good way to keep things simple.
The majority of attributes are implemented using text strings, but there are also routines for storing (and perhaps more importantly retrieving) numbers, pointers, etc. Depending on the interface element, some attributes are inheritable (for instance the BGCOLOR on an IupButton: if not specifically set, a button takes on the background colour of whatever control it is sitting on), and some attributes are non-inheritable (eg TITLE). Some must be set at creation time, ie before the dialog is first displayed (eg CANFOCUS), while others can be amended on the fly (eg ACTIVE), and some are read-only, or platform-specific. Whilst most attributes are static, referred to as needed, a few trigger actions when read or set (eg KEY). These are all documented for each element type.
You can also set bespoke application-specific attributes on any control, which the underlying platform-specific driver will completely ignore. The most likely thing I can think of where that might be useful would be to have a single callback that deals with several controls, which fetches an attribute off the control that triggered it, and tweaks the behaviour accordingly. Perhaps (I have not tried this) a clock application could have a single callback that gets called by three timers, and draws the hour, minute, and second hand appropriately, but I digress...
The point I am trying to make here is that, sheer number of different controls aside, by and large the core of IUP is jaw-droppingly trivial - all the important stuff gets controlled by attributes. Equally there are quite a few ways to set and retrieve attributes, of which there are plenty knocking about, but otherwise the attribute system itself is also conceptually quite trivial.