Planning to create a generic SDL-centric UI library

Well, I was looking around at all the other ones available, and none of them seemed to fit my desires or needs.

Currently my plans are as follows:

  • Small, practical library providing Widgets typical to most programs and minimal specialized widgets.
  • Minimal system-specific code for maximum portability and minimal complexity of compilation.
  • For SDL 1.3 (possibly with an SDL 1.2 compatibility layer like the one provided with SDL 1.3)
  • Programmer simply feeds an SDL event to a function that governs the UI operation, IE “void SDL_UI_Input(SDL_Event)”. This allows the programmer to control which events are fed to the UI, and use the events after the UI is done with them.
  • Skinning Facilities
  • Programmer can easily implement own input handling or rendering functions for specific widgets when the ones provided do not fit his/her purpose for the widget.
  • Programmer can easily implement and use his/her own widget types
  • Updates the screen only when programmer updates the screen in his/her own code (won’t make any choppiness with own mouse pointer, etc)
  • Position of widgets within widgets is relative to parent widget, not the screen (decreases programmer burden), and corrected for callbacks
  • Full Z-ordering, with programmer-defined depth (up to the built-in limit of whichever type I choose for the value)
  • Full Z-ordering for widgets within widgets (same as above).

I already have a pretty solid plan for it, as one could tell. However, before I get started, I was wondering if anyone else has anything they’d like to see in such a library?
I would value any input.[/code]

Well, I was looking around at all the other ones available, and none of them
seemed to fit my desires or needs.

Currently my plans are as follows:

  • Small, practical library providing Widgets typical to most programs and
    minimal specialized widgets.
  • Minimal system-specific code for maximum portability and minimal
    complexity of compilation.
  • For SDL 1.3 (possibly with an SDL 1.2 compatibility layer like the one
    provided with SDL 1.3)
  • Programmer simply feeds an SDL event to a function that governs the UI
    operation, IE “void SDL_UI_Input(SDL_Event)”. This allows the programmer to
    control which events are fed to the UI, and use the events after the UI is
    done with them.
  • Skinning Facilities
  • Programmer can easily implement own input handling or rendering functions
    for specific widgets when the ones provided do not fit his/her purpose for
    the widget.
  • Programmer can easily implement and use his/her own widget types
  • Updates the screen only when programmer updates the screen in his/her own
    code (won’t make any choppiness with own mouse pointer, etc)
  • Position of widgets within widgets is relative to parent widget, not the
    screen (decreases programmer burden), and corrected for callbacks
  • Full Z-ordering, with programmer-defined depth (up to the built-in limit
    of whichever type I choose for the value)
  • Full Z-ordering for widgets within widgets (same as above).

I already have a pretty solid plan for it, as one could tell. However,
before I get started, I was wondering if anyone else has anything they’d
like to see in such a library?
I would value any input.[/code]

What you have outlined sounds really good to me. The following is just
intended to bring up potential problem areas that I’ve run into.

SDL 1.3 currently support multiple windows, but not child windows. Are
you planning to implement widgets as regions of the a window, or by
putting them in separate windows that are positioned on top of the
window they are associated with. Both solutions have there own
problems.

The programmer has to set the color depth, and select any special
buffers or special features of the color buffers at the time he
creates and SDL_Window. Have you looked at how your UI is going to
work with double buffered windows? Or windows with stencil, depth, or
accumulation buffers? How about multisampled buffers? How does the
programmer communicate the location of the buffer the UI needs to
render into? I once ported X to a system where if double buffering was
turned on it had to be turned on for the entire screen. To get X to
work right I had to have every X drawing operation draw into both the
front and rear buffers. That way the clock kept ticking while graphics
applications were drawing into their back buffers and the screen
looked right after the buffers were swapped. Of course, we could only
support one double buffered application at a time, that application
could have several double buffered windows, but they all had to update
at the same time. Are you planning something similar to allow 2D
widgets to update out of synch with the 3D windows?

I assume you’ll have an OpenGL widget that the programmer will be able
to use as he pleases. If you use the one big window approach will you
provide an API to get the base transform and set the clipping
rectangles so the OpenGL calls will be properly scaled, transformed,
and clipped to fit in the drawing area and stay in the drawing area?

One last thing, you keep saying callbacks. Are these going to be C
call backs or C++ functors that wrap a class? Have you considered
using messages, or even the event queue instead?

Bob Pendleton


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It sounds like you are planning to use a painters algorithm toOn Wed, Nov 25, 2009 at 9:50 PM, nfries88 wrote:


±----------------------------------------------------------

Bob wrote:

SDL 1.3 currently support multiple windows, but not child windows. Are
you planning to implement widgets as regions of the a window, or by
putting them in separate windows that are positioned on top of the
window they are associated with. Both solutions have there own
problems.

Windows will be within the actual SDL-created window. I thought about child windows as well, but I figured that would require a lot of system-specific code which I don’t really want in the library. Instead I think that may be a good feature to add to SDL itself sometime, assuming all supported windowing systems allow it.

Bob wrote:

The programmer has to set the color depth, and select any special
buffers or special features of the color buffers at the time he
creates and SDL_Window. Have you looked at how your UI is going to
work with double buffered windows? Or windows with stencil, depth, or
accumulation buffers? How about multisampled buffers? How does the
programmer communicate the location of the buffer the UI needs to
render into? I once ported X to a system where if double buffering was
turned on it had to be turned on for the entire screen. To get X to
work right I had to have every X drawing operation draw into both the
front and rear buffers. That way the clock kept ticking while graphics
applications were drawing into their back buffers and the screen
looked right after the buffers were swapped. Of course, we could only
support one double buffered application at a time, that application
could have several double buffered windows, but they all had to update
at the same time. Are you planning something similar to allow 2D
widgets to update out of synch with the 3D windows?

The idea is for widgets to be updated whenever the programmer has SDL to update the window. This should prevent an issue like the UI not ever being updated even while the screen itself is updated, or apparent choppiness from updating it too much.
As far as how to deal with double-buffering, I hadn’t really thought of anything like that. However, since it will be using SDL for all rendering, I think it should just work however SDL works under those situations.

Bob wrote:

I assume you’ll have an OpenGL widget that the programmer will be able
to use as he pleases. If you use the one big window approach will you
provide an API to get the base transform and set the clipping
rectangles so the OpenGL calls will be properly scaled, transformed,
and clipped to fit in the drawing area and stay in the drawing area?

Well, this was the main idea behind the ability of the programmer being able to create his own widgets. Writing a widget with a unique rendering method and input handler would be trivial.

Bob wrote:

One last thing, you keep saying callbacks. Are these going to be C
call backs or C++ functors that wrap a class? Have you considered
using messages, or even the event queue instead?

Simple C functions. I was considering an event queue, but I figured simple callbacks that can be replaced or wrapped as needed was much simpler, and more fitting what I had in mind. The idea of a basic widget’s structure would be simple, like this:

Code:
typedef struct _UI_WidgetBase {
SDL_Rect region;
int z_pos;
void (OnRender)(struct _UI_WidgetBase);
int (EventHandler)(struct _UI_WidgetBase, SDL_Event);
} SDL_UI_WidgetBase;

with the OnRender pointing to the function containing code that renders the widget, and EventHandler pointing to a function that controls how the widget should react to events. The programmer using the library can simply create his own functions and point to those from this structure if the ones provided by the library do not meet his/her needs.
These functions will be called from a larger function which will control which widgets will be notified of the event, and intelligently determine the order in which they should be notified.

I’ve done this in a pretty similar fashion with C++ functions before (but with only Win32 and DirectX), and it was very flexible and simple to create widgets that operated completely differently than the others. However, if you can think of a reason why it’d be better to do something with a queue or messages, feel free to provide your input. I always value the input of someone more experienced than myself in these matters.

Hey,

I wrote a GUI lib that I think has everything you mentioned. I haven’t
worked on it in a while beside trying to fix the OpenGL rendering, but you
can take a look at it and steal whatever helps:
http://code.google.com/p/gro-gui/source/list

I think you should grab revision 2 if you can. If you have any questions
(there’s little documentation) or you want a newer version, let me know.

Jonny DOn Thu, Nov 26, 2009 at 4:38 PM, nfries88 wrote:

Bob wrote:

SDL 1.3 currently support multiple windows, but not child windows. Are
you planning to implement widgets as regions of the a window, or by
putting them in separate windows that are positioned on top of the
window they are associated with. Both solutions have there own
problems.

Windows will be within the actual SDL-created window. I thought about child
windows as well, but I figured that would require a lot of system-specific
code which I don’t really want in the library. Instead I think that may be a
good feature to add to SDL itself sometime, assuming all supported windowing
systems allow it.

Bob wrote:

The programmer has to set the color depth, and select any special
buffers or special features of the color buffers at the time he
creates and SDL_Window. Have you looked at how your UI is going to
work with double buffered windows? Or windows with stencil, depth, or
accumulation buffers? How about multisampled buffers? How does the
programmer communicate the location of the buffer the UI needs to
render into? I once ported X to a system where if double buffering was
turned on it had to be turned on for the entire screen. To get X to
work right I had to have every X drawing operation draw into both the
front and rear buffers. That way the clock kept ticking while graphics
applications were drawing into their back buffers and the screen
looked right after the buffers were swapped. Of course, we could only
support one double buffered application at a time, that application
could have several double buffered windows, but they all had to update
at the same time. Are you planning something similar to allow 2D
widgets to update out of synch with the 3D windows?

The idea is for widgets to be updated whenever the programmer has SDL to
update the window. This should prevent an issue like the UI not ever being
updated even while the screen itself is updated, or apparent choppiness from
updating it too much.
As far as how to deal with double-buffering, I hadn’t really thought of
anything like that. However, since it will be using SDL for all rendering, I
think it should just work however SDL works under those situations.

Bob wrote:

I assume you’ll have an OpenGL widget that the programmer will be able
to use as he pleases. If you use the one big window approach will you
provide an API to get the base transform and set the clipping
rectangles so the OpenGL calls will be properly scaled, transformed,
and clipped to fit in the drawing area and stay in the drawing area?

Well, this was the main idea behind the ability of the programmer being
able to create his own widgets. Writing a widget with a unique rendering
method and input handler would be trivial.

Bob wrote:

One last thing, you keep saying callbacks. Are these going to be C
call backs or C++ functors that wrap a class? Have you considered
using messages, or even the event queue instead?

Simple C functions. I was considering an event queue, but I figured simple
callbacks that can be replaced or wrapped as needed was much simpler, and
more fitting what I had in mind. The idea of a basic widget’s structure
would be simple, like this:

Code:

typedef struct _UI_WidgetBase {
SDL_Rect region;
int z_pos;
void (OnRender)(struct _UI_WidgetBase);
int (EventHandler)(struct _UI_WidgetBase, SDL_Event);
} SDL_UI_WidgetBase;

with the OnRender pointing to the function containing code that renders the
widget, and EventHandler pointing to a function that controls how the widget
should react to events. The programmer using the library can simply create
his own functions and point to those from this structure if the ones
provided by the library do not meet his/her needs.
These functions will be called from a larger function which will control
which widgets will be notified of the event, and intelligently determine the
order in which they should be notified.

I’ve done this in a pretty similar fashion with C++ functions before (but
with only Win32 and DirectX), and it was very flexible and simple to create
widgets that operated completely differently than the others. However, if
you can think of a reason why it’d be better to do something with a queue or
messages, feel free to provide your input. I always value the input of
someone more experienced than myself in these matters.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jonny D wrote:

Hey,

I wrote a GUI lib that I think has everything you mentioned. ?I haven’t worked on it in a while beside trying to fix the OpenGL rendering, but you can take a look at it and steal whatever helps:
http://code.google.com/p/gro-gui/source/list (http://code.google.com/p/gro-gui/source/list)

I think you should grab revision 2 if you can. ?If you have any questions (there’s little documentation) or you want a newer version, let me know.

Jonny D

It looks like it may be of use to me. Thanks.

Something I hadn’t thought of - what about fonts?
Right now I’m thinking to create generic “struct _UI_FONT” and “struct _UI_UNIFONT” that only provides a skeleton for font rendering, leaving the programmer to actually implement it.
Also, if I do that, should I include a wrapper for this around SDL_ttf?

So, what should I use for handling text input? The new text input API, or the old keyboard input events?
What are the differences and what would be the advantages to using the text input API vice the old one?

The new text input API is more friendly for internationalization,
since it doesn’t assume that a single key maps to a single character.On Thu, Dec 10, 2009 at 4:46 PM, nfries88 wrote:

So, what should I use for handling text input? The new text input API, or
the old keyboard input events?
What are the differences and what would be the advantages to using the text
input API vice the old one?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam Lantinga wrote:> The new text input API is more friendly for internationalization,

since it doesn’t assume that a single key maps to a single character.

On Thu, Dec 10, 2009 at 4:46 PM, nfries88 <@Nathaniel_J_Fries> wrote:

So, what should I use for handling text input? The new text input API, or
the old keyboard input events?
What are the differences and what would be the advantages to using the text
input API vice the old one?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But the events use an array of type char O_o
am I supposed to know what type it is and cast, or what?

Also, is there any sort of documentation on it? The more complete 1.3 reference wiki that I’ve found is still largely incomplete and it doesn’t have any information on the structures or how they’re used.


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sam Lantinga wrote:

The new text input API is more friendly for internationalization,
since it doesn’t assume that a single key maps to a single character.

Quote:

So, what should I use for handling text input? The new text input API, or
the old keyboard input events?
What are the differences and what would be the advantages to using the text
input API vice the old one?


SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But the events use an array of type char O_o
am I supposed to know what type it is and cast, or what?

Nope, it is actually char data. The characters are encoded as UTF-8. SDL 1.3
uses UTF-8 for all (or at least all I’ve looked at) text.

Also, is there any sort of documentation on it? The more complete 1.3
reference wiki that I’ve found is still largely incomplete and it doesn’t
have any information on the structures or how they’re used.

Right now I trust the source, and nothing but the source, so help me Sam!
One good approach is run doxygen over the source to generate the latest and
greatest documentation. I just keep it all checked out and once in a while I
run doxygen. If the doxygen docs aren’t good enough, I read the code. This
is far from ideal, but it is the state of things at this point in the
development of 1.3. Sam has been adding, modifying, and correcting the
documentation in the code as he goes along. So have everyone else who
touches the code. Even folks sending in patches are fixing, and adding docs.
By far the best thing people can do right now and probably for the next few
years is to read the doxygen docs and expand them, correct them, update
them.

This is an open source project where Sam does most of the work and we get
most of the benefits. The least we can do is help with the documentation.

Bob PendletonOn Fri, Dec 11, 2009 at 3:20 PM, nfries88 wrote:

On Thu, Dec 10, 2009 at 4:46 PM, nfries88 <> wrote:


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

Bob wrote:

Nope, it is actually char data. The characters are encoded as UTF-8. SDL 1.3 uses UTF-8 for all (or at least all I’ve looked at) text.

So, there are currently no events for UTF16 or UTF32?

Bob wrote:

Nope, it is actually char data. The characters are encoded as UTF-8. SDL
1.3 uses UTF-8 for all (or at least all I’ve looked at) text.

So, there are currently no events for UTF16 or UTF32?

That is correct. It is about the only thing to use in a cross platform
library. Especially when you consider the lack of a standard size for
wchar_t.

Bob PendletonOn Fri, Dec 11, 2009 at 11:22 PM, nfries88 wrote:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

Well, I honestly haven’t had much time to work on this. I’ve “wasted” plenty of time mulling over the design, but never actually wrote any implementation.
I knew I would pretty busy so I figured it might happen… but I think I have a pretty solid design plan now, and I just want some constructive criticism on it.

At first I thought about writing it in C++ - I’ve done much more work in C++ and honestly find it a little difficult to write anything big in C due to lack of basic object-oriented features being built into the language (mostly implicit constructors and destructors). I actually wrote about 15 hours worth of code before I decided to scrap this due to the fact that I want something all SDL developers can use, even the ones that don’t want to touch C++ (and figured most of those developers have their reasons).

So then I thought about how I’d handle it in C without dropping any of my plans. The first idea was to make a basic structure containing the “small stuff” a widget would need - position, width, height, etc. Then the other widgets would just contain an instance of this structure as their respective struct’s first member. This works great for C, but when C++'s strict typesafety came to mind… I decided it was best to scrap this for ease of programming in both languages (without making some C++ wrapper or having to implement separate functions for each widget type).

Then I thought about using unions. This did seem like the best option of them all, until I realized that I had no clue how much memory was available on the iPhone and other potential target devices for SDL. After investigating and finding people saying that the original iPhone had 128mb of RAM with the system using as much as 40% of that, and even less on my beloved G1, I decided that I needed to do whatever I could to trim down on the memory usage so that the application using the library could use as much as possible for its graphics and internal operations – this is where I spent a lot of time thinking. Why should a simple widget like a button consume as much memory as a more complex widget like a window? Was it even wise for it do so with this little memory? I figured it would probably have been fine, but ended up scrapping the design just-in-case.

Making an inheritance model consume little memory seemed difficult, until I thought about a programming concept I had nearly forgotten because it’s not an enforced feature of C++ – interfaces. A table of functions defining the operation of a specific type of widget, and occupying the same memory for each instance of that type of widget, would increase the memory usage just by implementing them by a bit, but overall less (especially in the case of a complex GUI).

So, here’s a small sample of the concept:

Code:

struct __UI_WInterface;

typedef struct __UI_Widget {
struct __UI_WInterface* interface; /* generic interface /
struct __UI_Widget
container; /* widget containing this one /
size_t wDataSize; /
size of wData in bytes /
void
wData; /* pointer to data structure for the widget, used internally by the implementation */
} SDL_UI_Widget;

struct __UI_WContainInterface;
struct __UI_WSkinner;

typedef struct __UI_WInterface {
struct __UI_WContainInterface* containInterface; /* interface used only by widgets containing other widgets, but common enough for explicit definition /
struct __UI_WSkinner
skinner; /* user-defined function for skinning a widget, maybe belongs in SDL_UI_Widget? /
void (GetPos)(SDL_UI_Widget, int
x, int* y); /* get the position of the widget relative to its container /
void (SetPos)(SDL_UI_Widget, int x, int y); /
set position of the widget relative to its owner; there is no need for a function
void (GetAbsPos)(SDL_UI_Widget, int* x, int* y); /* get the absolute position of the widget (from the top-left corner of window) /
void (GetSize)(SDL_UI_Widget, int
w, int* h); /* get the dimensions of the widget /
void (SetSize)(SDL_UI_Widget, int w, int h); /
set the dimensions of the widget /
void (RenderFunction)(SDL_UI_Widget); /
perform rendering /
void (EventHandler)(SDL_UI_Widget, SDL_Event
); /* handle an event from SDL /
size_t wIExtendedSize; /
size of data pointed to by wIExtended /
void
wIExtended; /* extended interface function */
} SDL_UI_WInterface;

[…]

/* implementation must define a version of this function for each type of widget – widget must be pre-allocated memory */
typedef int (SDL_UI_WidgetFactory)(SDL_UI_Widget widget);

/* register a pre-filled WInterface with identifier and widget factory, where it will be stored in an associative array /
int SDL_UI_RegisterInterface(SDL_UI_WInterface
wInterface, const char* identifier, SDL_UI_WidgetFactory factory);

/* fetch an interface by its identifier - leave this as an external function only for the sake of custom widget implementations /
SDL_UI_WInterface
SDL_UI_GetInterface(const char* identifier);

/* abstract widget creation by identifier – widget must be preallocated memory /
int SDL_UI_CreateWidget(SDL_UI_Widget
widget, const char* identifier);
[…]

The design is simple enough, I shouldn’t need to explain further.

The size of an individual widget instance is cut to that of 4 pointers (since the size of size_t should be the same as a pointer). If there’s only 5 widgets being used, this is a huge waste. If there’s 50, it’s probably getting a bit useful. 500 (is this a common number for any type of application?), it’s probably important. Honestly though I probably spent a bit too much time focusing on the memory consumption issue… and I don’t even know if this will benefit many realistic SDL 1.3 apps.

Also, as one might see, the functions I’ve shown as required for implementation are influenced by the Win32 API. Win32 API was my first experience with GUI programming and it seemed like a good way to do it without largely changing the method of widget creation between implementations…

If you really to attract C programmers, then forget about containers,events
all of that. Like you said, C lacks basic object-orientated features.
(struct deserves an honorable mention) Every uses their own event loop
anyways. People are use to managing their own objects in SDL. You don’t need
to write routines that focus on the objects being ‘aware’ each other.

I would be happier with a standard set of calls that did nothing but draw
familiar images to the screen and return SDL_rects. A legit clipart set
wouldn’t hurt.On Thu, Mar 4, 2010 at 12:27 AM, nfries88 wrote:

Well, I honestly haven’t had much time to work on this. I’ve "wasted"
plenty of time mulling over the design, but never actually wrote any
implementation.
I knew I would pretty busy so I figured it might happen… but I think I
have a pretty solid design plan now, and I just want some constructive
criticism on it.

At first I thought about writing it in C++ - I’ve done much more work in
C++ and honestly find it a little difficult to write anything big in C due
to lack of basic object-oriented features being built into the language
(mostly implicit constructors and destructors). I actually wrote about 15
hours worth of code before I decided to scrap this due to the fact that I
want something all SDL developers can use, even the ones that don’t want to
touch C++ (and figured most of those developers have their reasons).

So then I thought about how I’d handle it in C without dropping any of my
plans. The first idea was to make a basic structure containing the “small
stuff” a widget would need - position, width, height, etc. Then the other
widgets would just contain an instance of this structure as their respective
struct’s first member. This works great for C, but when C++'s strict
typesafety came to mind… I decided it was best to scrap this for ease of
programming in both languages (without making some C++ wrapper or having to
implement separate functions for each widget type).

Then I thought about using unions. This did seem like the best option of
them all, until I realized that I had no clue how much memory was available
on the iPhone and other potential target devices for SDL. After
investigating and finding people saying that the original iPhone had 128mb
of RAM with the system using as much as 40% of that, and even less on my
beloved G1, I decided that I needed to do whatever I could to trim down on
the memory usage so that the application using the library could use as much
as possible for its graphics and internal operations – this is where I
spent a lot of time thinking. Why should a simple widget like a button
consume as much memory as a more complex widget like a window? Was it even
wise for it do so with this little memory? I figured it would probably have
been fine, but ended up scrapping the design just-in-case.

Making an inheritance model consume little memory seemed difficult, until I
thought about a programming concept I had nearly forgotten because it’s not
an enforced feature of C++ – interfaces. A table of functions defining the
operation of a specific type of widget, and occupying the same memory for
each instance of that type of widget, would increase the memory usage just
by implementing them by a bit, but overall less (especially in the case of a
complex GUI).

So, here’s a small sample of the concept:

Code:

struct __UI_WInterface;

typedef struct __UI_Widget {
struct __UI_WInterface* interface; /* generic interface /
struct __UI_Widget
container; /* widget containing this one /
size_t wDataSize; /
size of wData in bytes /
void
wData; /* pointer to data structure for the widget, used
internally by the implementation */
} SDL_UI_Widget;

struct __UI_WContainInterface;
struct __UI_WSkinner;

typedef struct __UI_WInterface {
struct __UI_WContainInterface* containInterface; /* interface used only
by widgets containing other widgets, but common enough for explicit
definition /
struct __UI_WSkinner
skinner; /* user-defined function for skinning a
widget, maybe belongs in SDL_UI_Widget? /
void (GetPos)(SDL_UI_Widget, int
x, int* y); /* get the position of
the widget relative to its container /
void (SetPos)(SDL_UI_Widget, int x, int y); /
set position of the
widget relative to its owner; there is no need for a function
void (GetAbsPos)(SDL_UI_Widget, int* x, int* y); /* get the absolute
position of the widget (from the top-left corner of window) /
void (GetSize)(SDL_UI_Widget, int
w, int* h); /* get the dimensions
of the widget /
void (SetSize)(SDL_UI_Widget, int w, int h); /
set the dimensions of
the widget /
void (RenderFunction)(SDL_UI_Widget); /
perform rendering /
void (EventHandler)(SDL_UI_Widget, SDL_Event
); /* handle an event
from SDL /
size_t wIExtendedSize; /
size of data pointed to by wIExtended /
void
wIExtended; /* extended interface function */
} SDL_UI_WInterface;

[…]

/* implementation must define a version of this function for each type of
widget – widget must be pre-allocated memory */
typedef int (SDL_UI_WidgetFactory)(SDL_UI_Widget widget);

/* register a pre-filled WInterface with identifier and widget factory,
where it will be stored in an associative array /
int SDL_UI_RegisterInterface(SDL_UI_WInterface
wInterface, const char*
identifier, SDL_UI_WidgetFactory factory);

/* fetch an interface by its identifier - leave this as an external
function only for the sake of custom widget implementations /
SDL_UI_WInterface
SDL_UI_GetInterface(const char* identifier);

/* abstract widget creation by identifier – widget must be preallocated
memory /
int SDL_UI_CreateWidget(SDL_UI_Widget
widget, const char* identifier);
[…]

The design is simple enough, I shouldn’t need to explain further.

The size of an individual widget instance is cut to that of 4 pointers
(since the size of size_t should be the same as a pointer). If there’s only
5 widgets being used, this is a huge waste. If there’s 50, it’s probably
getting a bit useful. 500 (is this a common number for any type of
application?), it’s probably important. Honestly though I probably spent a
bit too much time focusing on the memory consumption issue… and I don’t
even know if this will benefit many realistic SDL 1.3 apps.

Also, as one might see, the functions I’ve shown as required for
implementation are influenced by the Win32 API. Win32 API was my first
experience with GUI programming and it seemed like a good way to do it
without largely changing the method of widget creation between
implementations…


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If you really to attract C programmers, then forget about
containers,events all of that. Like you said, C lacks basic
object-orientated features. (struct deserves an honorable mention)

Well, you can still do OO-ish stuff in C. Objective-C adds very little
to C and you can actually call the Objective-C runtime from C without
the messaging syntax and treat objects as structs, if you want.

If you don’t need implicit constructors/destructors you can write
reasonably OO-ish C programs, in fact, if you can live with the
inefficiency of using setter/getter functions for every field, you
don’t even have to describe the actual structure in the header file,
just use a typedef for the opaque struct pointer. I think in case of a
GUI efficiency is less of an issue, your code is not going to spend too
much time in the GUI bit anyway.

Of course I’m a heavily entrenched C programmer, so my view is
rather biased… :-)On Thu, 4 Mar 2010 02:39:04 -0500 Jeremiah wrote:

Jeremiah wrote:

Every uses their own event loop anyways. People are use to managing their own objects in SDL. You don’t need to write routines that focus on the objects being ‘aware’ each other.

I would be happier with a standard set of calls that did nothing but draw familiar images to the screen and return SDL_rects. A legit clipart set wouldn’t hurt.

“Clipart” seems like something the end program should supply. That, or I’m misinterpreting you.
As for the approach, I completely hadn’t thought of it – and it would be a great way to do it as long as SDL veterans are what I’m attracting: but I’m trying to attract anyone who wants to use SDL. I want something that advanced users who are used to handling their own objects can use, but at the same time a design that’s extensive enough to be able to provide a healthy GUI system to someone who hasn’t done more than glanced over some SDL code before.
And my current design doesn’t take over the event loop or anything it’s explicitly sent an event by the programmer and then it’s handled internally; though I guess I forgot to mention that. This leaves control of the entire main loop in the programmer’s hand, including pre-processing of events at the programmer’s discretion (maybe you don’t want arrow keys affecting the UI at all unless the SHIFT key is held down to prevent the UI from interfering with gameplay – you can do that without touching the implementation).

Zolt??n K??csi wrote:

If you don’t need implicit constructors/destructors you can write
reasonably OO-ish C programs, in fact, if you can live with the
inefficiency of using setter/getter functions for every field, you
don’t even have to describe the actual structure in the header file,
just use a typedef for the opaque struct pointer. I think in case of a
GUI efficiency is less of an issue, your code is not going to spend too
much time in the GUI bit anyway.

You’re telling me nothing new. If I wanted to ignore the C++ userbase, this would be a decent option (and in a way I already do this anyway – all I specify for actual widget information is size_t and a void*, I just retain the interface)

Just thought I’d mentioned it. A UI library with no art is going to be
pretty boring.

Better looking screenshots will get even more people, than code. Given the
nature of library, its best to advantage of this.

Best SDL ui library —> http://code.google.com/p/pgu/

That’s the one new people use. When their programming in Python atleast.
Borrow some of their graphics. Might as well take the names too. I like the
table container.
Another keeper.

If you’re attempting make functions like that you’ll definitely need art at
that point. How will you know if your code works, if you don’t have anything
to draw?
Proof of concept is going to need to be more than just words and code.On Thu, Mar 4, 2010 at 6:47 AM, nfries88 wrote:

“Clipart” seems like something the end program should supply. That, or I’m
misinterpreting you.

As for the approach, I completely hadn’t thought of it – and it would be
a great way to do it as long as SDL veterans are what I’m attracting: but
I’m trying to attract anyone who wants to use SDL. I want something that
advanced users who are used to handling their own objects can use, but at
the same time a design that’s extensive enough to be able to provide a
healthy GUI system to someone who hasn’t done more than glanced over some
SDL code before.
And my current design doesn’t take over the event loop or anything it’s
explicitly sent an event by the programmer and then it’s handled internally;
though I guess I forgot to mention that. This leaves control of the entire
main loop in the programmer’s hand, including pre-processing of events at
the programmer’s discretion (maybe you don’t want arrow keys affecting the
UI at all unless the SHIFT key is held down to prevent the UI from
interfering with gameplay – you can do that without touching the
implementation).

Zolt??n K??csi wrote:

If you don’t need implicit constructors/destructors you can write
reasonably OO-ish C programs, in fact, if you can live with the
inefficiency of using setter/getter functions for every field, you
don’t even have to describe the actual structure in the header file,
just use a typedef for the opaque struct pointer. I think in case of a
GUI efficiency is less of an issue, your code is not going to spend too
much time in the GUI bit anyway.

You’re telling me nothing new. If I wanted to ignore the C++ userbase, this
would be a decent option (and in a way I already do this anyway – all I
specify for actual widget information is size_t and a void*, I just retain
the interface)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yay for C! so far my iphone SDL app has required me to write zero lines
of objective-c so I am happy.

On the subject of a UI library I have been doing just the same, and now
that I look at it I basically do have “classes” ( sprite, button, text )
and derived classes ( text_button, sprite_button ). I’d be intrested how
you progress along. My needs were for pure opengl-es plus SDL for
events, but a more general one will help lots of people and stop them
from re-inventing wheels like meOn Thu, 2010-03-04 at 22:13 +1100, Zolt?n K?csi wrote:

On Thu, 4 Mar 2010 02:39:04 -0500 Jeremiah wrote:

If you really to attract C programmers, then forget about
containers,events all of that. Like you said, C lacks basic
object-orientated features. (struct deserves an honorable mention)

Well, you can still do OO-ish stuff in C. Objective-C adds very little
to C and you can actually call the Objective-C runtime from C without
the messaging syntax and treat objects as structs, if you want.

If you don’t need implicit constructors/destructors you can write
reasonably OO-ish C programs, in fact, if you can live with the
inefficiency of using setter/getter functions for every field, you
don’t even have to describe the actual structure in the header file,
just use a typedef for the opaque struct pointer. I think in case of a
GUI efficiency is less of an issue, your code is not going to spend too
much time in the GUI bit anyway.

Of course I’m a heavily entrenched C programmer, so my view is
rather biased… :slight_smile: