SDL-widgets GUI toolkit, new version

Hello,

Version 0.2 of GUI toolkit SDL-widgets has been released:
http://members.chello.nl/w.boeke/SDL-widgets/index.html

SDL-widgets is aiming at normal applications, not especially games.
In the past, version 0.1 has been upgraded silently, but now it
seems to be the right time to apply the next version number, as
several new widgets have been added.

The progression of SDL-widgets is rather slow, which results
from the fact that I use it myself for new audio applications,
which is a difficult endeavour. I am hoping that the toolkit is of
some use for others too.

Regards,
Wouter Boeke

It looks nice! May I ask why you aren’t using GTK+ or something like that?On Sun, Feb 15, 2009 at 12:04 PM, W.Boeke <w.boeke at chello.nl> wrote:

Hello,

Version 0.2 of GUI toolkit SDL-widgets has been released:
http://members.chello.nl/w.boeke/SDL-widgets/index.html

SDL-widgets is aiming at normal applications, not especially games.
In the past, version 0.1 has been upgraded silently, but now it
seems to be the right time to apply the next version number, as
several new widgets have been added.

The progression of SDL-widgets is rather slow, which results
from the fact that I use it myself for new audio applications,
which is a difficult endeavour. I am hoping that the toolkit is of
some use for others too.

Regards,
Wouter Boeke


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


http://codebad.com/

It really does look nice. I’m working on a GUI library too, which is more
intended for games. I’m interested in seeing how others have approached
problems like input handling, event handling, and rendering and I’m
especially interested in unique widgets and new ideas. I like the fallbacks
you have that send output to stdout, and I think wav2spectrum could be a
useful resource.

I’ll probably be mentioning my lib again on the list soon. For me, the
choice to stay away from GTK+ (and others) was because I can do much better
in terms of simplicity and true flexibility.

Jonny DOn Sun, Feb 15, 2009 at 2:36 PM, Donny Viszneki <donny.viszneki at gmail.com>wrote:

It looks nice! May I ask why you aren’t using GTK+ or something like that?

On Sun, Feb 15, 2009 at 12:04 PM, W.Boeke <w.boeke at chello.nl> wrote:

Hello,

Version 0.2 of GUI toolkit SDL-widgets has been released:
http://members.chello.nl/w.boeke/SDL-widgets/index.html

SDL-widgets is aiming at normal applications, not especially games.
In the past, version 0.1 has been upgraded silently, but now it
seems to be the right time to apply the next version number, as
several new widgets have been added.

The progression of SDL-widgets is rather slow, which results
from the fact that I use it myself for new audio applications,
which is a difficult endeavour. I am hoping that the toolkit is of
some use for others too.

Regards,
Wouter Boeke


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


http://codebad.com/


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

your configure script and sdl-widgets.cpp has the path to the font hard
coded. i had to fix that with sed on gentoo.

hard coded path:
/usr/share/fonts/truetype/freefont/FreeSans.ttf

gentoo:
/usr/share/fonts/freefont-ttf/FreeSans.ttf

after fixing this in those 2 files, the font is still not found.

matt at noose /tmp/SDL-widgets-0.2 $ grep -R FreeSans.ttf *
configure:if [ ls -d /usr/share/fonts/freefont-ttf/FreeSans.ttf ]
Binary file examples/wav2spectrum matches
Binary file examples/hello matches
Binary file examples/make-waves matches
sdl-widgets.cpp: err(“font-spec FreeSans.ttf not found”);
sdl-widgets.cpp: if (!(def_font=TTF_OpenFont( “/usr/share/fonts/freefont-ttf/FreeSans.ttf”,nominal_font_size)))
sdl-widgets.cpp: err(“font-spec FreeSans.ttf not found”);
Binary file sdl-widgets.o matches
Binary file testsw matches
matt at noose /tmp/SDL-widgets-0.2 $

matt at noose /tmp/SDL-widgets-0.2 $ ls -l /usr/share/fonts/freefont-ttf/FreeSans.ttf
-rw-r–r-- 1 root root 465152 Feb 15 15:32 /usr/share/fonts/freefont-ttf/FreeSans.ttf
matt at noose /tmp/SDL-widgets-0.2 $

mattOn Sun, 15 Feb 2009, W.Boeke wrote:

Hello,

Version 0.2 of GUI toolkit SDL-widgets has been released:
http://members.chello.nl/w.boeke/SDL-widgets/index.html

SDL-widgets is aiming at normal applications, not especially games.
In the past, version 0.1 has been upgraded silently, but now it
seems to be the right time to apply the next version number, as
several new widgets have been added.

The progression of SDL-widgets is rather slow, which results
from the fact that I use it myself for new audio applications,
which is a difficult endeavour. I am hoping that the toolkit is of
some use for others too.

Regards,
Wouter Boeke


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

mattmatteh at mac.com wrote:

your configure script and sdl-widgets.cpp has the path to the font hard
coded. i had to fix that with sed on gentoo.

hard coded path:
/usr/share/fonts/truetype/freefont/FreeSans.ttf

gentoo:
/usr/share/fonts/freefont-ttf/FreeSans.ttf

Hi Matt,
My fault! Maybe I should expect more posts with similar compatibility
problems.
I adopted the configure script such that it really searches for the font
file, and placed a new SDL-widgets-0.2.tar.gz on the web site.

Wouter Boeke

Donny Viszneki wrote:

It looks nice! May I ask why you aren’t using GTK+ or something like that?

Hi Donny,

I know there are many good toolkits, and one of them is GTK+. This one is
written in C but they tried to make it more or less Object Oriented.
That’s not really possible in C, so the type checking is done at runtime.
In order to fix this, GTKmm was created, which is kind of a C++ wrapper
around GTK+, and type checking is enabled by templates.

In my opinion all this trouble originates from the fact that only one callback
function is used for all types of widgets, with a void* pointer in its
parameter list. Thus the user has to put a typecast in the body of the
callback function, and the compiler cannot check this.

In the SDL-widgets toolkit each kind of widget has its own callback function,
with a parameter list as needed for this widget. The compiler can fully
check this at compile time, wich is very convenient especially when you
modify your data structures etc. later on.

Another motivation for my DIY approach was that I wanted messages for
inter-thread communication, which yields carefree operation especially for
audio applications.

Wouter Boeke

On Haiku we expect to see it in /boot/common/lib and /boot/common/share
Perhaps enable PREFIX, we normally pass --prefix=/boot/common to
./configure and all is taken care of there.

Also I can’t seem to locate an lrint:
/boot/home/SDL-widgets-0.2/examples/wav2spectrum.cpp:208: implicit
declaration of function `int lrint(…)’

and got some warning for “warning: declaration of `y0’ shadows global
declaration”, also on y1, and div.
-scottmcOn Mon, Feb 16, 2009 at 8:31 AM, W.Boeke <w.boeke at chello.nl> wrote:

mattmatteh at mac.com wrote:

your configure script and sdl-widgets.cpp has the path to the font hard
coded. i had to fix that with sed on gentoo.

hard coded path:
/usr/share/fonts/truetype/freefont/FreeSans.ttf

gentoo:
/usr/share/fonts/freefont-ttf/FreeSans.ttf

Hi Matt,
My fault! Maybe I should expect more posts with similar compatibility
problems.
I adopted the configure script such that it really searches for the font
file, and placed a new SDL-widgets-0.2.tar.gz on the web site.

Wouter Boeke


Compiled successfully on my Ubuntu 64, demos run perfectly.

— En date de?: Dim 15.2.09, W.Boeke <w.boeke at chello.nl> a ?crit?:de: W.Boeke <w.boeke at chello.nl>
Objet: [SDL] SDL-widgets GUI toolkit, new version
?: sdl at lists.libsdl.org
Date: Dimanche 15 F?vrier 2009, 18h04

Hello,

Version 0.2 of GUI toolkit SDL-widgets has been released:
http://members.chello.nl/w.boeke/SDL-widgets/index.html

SDL-widgets is aiming at normal applications, not especially games.
In the past, version 0.1 has been upgraded silently, but now it
seems to be the right time to apply the next version number, as
several new widgets have been added.

The progression of SDL-widgets is rather slow, which results
from the fact that I use it myself for new audio applications,
which is a difficult endeavour. I am hoping that the toolkit is of
some use for others too.

Regards,
Wouter Boeke


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

  __________________________________________________________________________________________________

Ne pleurez pas si votre Webmail ferme ! R?cup?rez votre historique sur Yahoo! Mail ! http://fr.docs…yahoo.com/mail/transfert_mails.html

scott mc wrote:

On Haiku we expect to see it in /boot/common/lib and /boot/common/share
Perhaps enable PREFIX, we normally pass --prefix=/boot/common to
./configure and all is taken care of there

Also I can’t seem to locate an lrint:
/boot/home/SDL-widgets-0.2/examples/wav2spectrum.cpp:208: implicit
declaration of function `int lrint(…)’

Hi Scott,

Hello Haiku! I learned GUI programming under BeOS. One problem was that
POSIX compliance had been implemented afterwards by BE inc., which resulted in
much redundant functionality in the libraries. Probably Haiku has the same
problem, because of the needed backwards compatibility?

Anyhow, for the moment please insert the following code in wav2spectrum.cpp:

static int lrint (float x) {
if (x < 0) return int(x - 0.5);
return int(x + 0.5);
}

and got some warning for “warning: declaration of `y0’ shadows global
declaration”, also on y1, and div.

I do not understand this: there is no global y0 etc.

Wouter Boeke

scott mc wrote:

On Haiku we expect to see it in /boot/common/lib and /boot/common/share
Perhaps enable PREFIX, we normally pass --prefix=/boot/common to
./configure and all is taken care of there

Hi Scott,

Would you mind to modify the configure script yourself? Later on it will
be adepted like you suggested. So instead of the line:

FONTPATH=find /usr/share/fonts -name FreeSans.ttf

you write:

FONTPATH=find /boot/common -name FreeSans.ttf

Wouter Boeke

I know there are many good toolkits, and one of them is GTK+. This one is
written in C but they tried to make it more or less Object Oriented.
That’s not really possible in C, so the type checking is done at runtime.
In order to fix this, GTKmm was created, which is kind of a C++ wrapper
around GTK+, and type checking is enabled by templates.

This is exactly the answer I realized you would give me while looking
around your website and saw that you were an ML coder :wink:

Another motivation for my DIY approach was that I wanted messages for
inter-thread communication, which yields carefree operation especially for
audio applications.

FYI, glib/GTK+ provides some pretty good APIs to deal with this issue as well!

P.S.: I second Jonathan Dearborn’s interest in wav2spectrum!On Mon, Feb 16, 2009 at 4:04 AM, W.Boeke <w.boeke at chello.nl> wrote:


http://codebad.com/

It’s possible to write object oriented code in any Turing complete language,
it’s just a heck of a lot easier in languages that were designed for OOP. The
first C++ compilers didn’t translate directly into machine or intermediate
code, they translated C++ source into C source which was then compiled by the
system’s C compiler.

JeffOn Monday 16 February 2009 01:04, W.Boeke wrote:

I know there are many good toolkits, and one of them is GTK+. This one is
written in C but they tried to make it more or less Object Oriented.
That’s not really possible in C, so the type checking is done at runtime.

Jeff Post wrote:> On Monday 16 February 2009 01:04, W.Boeke wrote:

I know there are many good toolkits, and one of them is GTK+. This one is
written in C but they tried to make it more or less Object Oriented.
That’s not really possible in C, so the type checking is done at runtime.

It’s possible to write object oriented code in any Turing complete language,
it’s just a heck of a lot easier in languages that were designed for OOP. The
first C++ compilers didn’t translate directly into machine or intermediate
code, they translated C++ source into C source which was then compiled by the
system’s C compiler.

Hi Jeff,

I’m sorry to disagree with you. The difference is between “compile-time
typechecking” and “run-time typechecking”. The former can only be done
in a OO language featuring function-overloading and virtual functions.

And about that translating to C by the first C++ compilers … During the
translation a lot of extra variables and macro’s where inserted, e.g.
in order to generate unique function names for each method and function.
It is not completely impossible to do this by hand of course, but why
would you?

Wouter Boeke

But there C was more used like a high level assembler.

You weren’t supposed to look at the generated code, unless you were trying
to sort out some optimization or compiler
problem.–
Paulo

On Mon, Feb 16, 2009 at 4:13 PM, Jeff Post <j_post at pacbell.net> wrote:

On Monday 16 February 2009 01:04, W.Boeke wrote:

I know there are many good toolkits, and one of them is GTK+. This one is
written in C but they tried to make it more or less Object Oriented.
That’s not really possible in C, so the type checking is done at runtime.

It’s possible to write object oriented code in any Turing complete
language,
it’s just a heck of a lot easier in languages that were designed for OOP.
The
first C++ compilers didn’t translate directly into machine or intermediate
code, they translated C++ source into C source which was then compiled by
the
system’s C compiler.

Jeff


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

Donny Viszneki wrote:

This is exactly the answer I realized you would give me while looking
around your website and saw that you were an ML coder :wink:

Hi Donny,

Clever that you found me on the web. Indeed I liked ML in the past,
however I found out that ML programs ported to C++ could be as simple
and as short as the original. However, ML coding is fun, especially
the translation from your natural sequential way of thinking towards
recursive functions. Also, ML can never crash at runtime, and you do
not need a debugger.

Wouter

Hi,

I also had lots of fun with Caml several years ago.

I find really cool that nowadays due to the multicore usage on the desktop,
funcional languages
are getting more industry support. Scala on Java world and F# on the .Net.

And there is the increase usage of Haskell in some places.

Sorry for the OT, but funcional is cool, if you can get your head around it
that is.–
Paulo

On Mon, Feb 16, 2009 at 5:17 PM, W.Boeke <w.boeke at chello.nl> wrote:

Donny Viszneki wrote:

This is exactly the answer I realized you would give me while looking
around your website and saw that you were an ML coder :wink:

Hi Donny,

Clever that you found me on the web. Indeed I liked ML in the past,
however I found out that ML programs ported to C++ could be as simple
and as short as the original. However, ML coding is fun, especially
the translation from your natural sequential way of thinking towards
recursive functions. Also, ML can never crash at runtime, and you do
not need a debugger.

Wouter


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

I can tell you that I do not have fun with Scheme…

Jonny DOn Mon, Feb 16, 2009 at 11:56 AM, Paulo Pinto wrote:

Hi,

I also had lots of fun with Caml several years ago.

I find really cool that nowadays due to the multicore usage on the desktop,
funcional languages
are getting more industry support. Scala on Java world and F# on the .Net.

And there is the increase usage of Haskell in some places.

Sorry for the OT, but funcional is cool, if you can get your head around it
that is.


Paulo

On Mon, Feb 16, 2009 at 5:17 PM, W.Boeke <w.boeke at chello.nl> wrote:

Donny Viszneki wrote:

This is exactly the answer I realized you would give me while looking
around your website and saw that you were an ML coder :wink:

Hi Donny,

Clever that you found me on the web. Indeed I liked ML in the past,
however I found out that ML programs ported to C++ could be as simple
and as short as the original. However, ML coding is fun, especially
the translation from your natural sequential way of thinking towards
recursive functions. Also, ML can never crash at runtime, and you do
not need a debugger.

Wouter


SDL mailing list
SDL at lists.libsdl.org
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

I’m sorry to disagree with you. The difference is between “compile-time
typechecking” and “run-time typechecking”. The former can only be done
in a OO language featuring function-overloading and virtual functions.

This is true, but to be pedantic, that’s just getting the compiler to do work
you could do manually.

And about that translating to C by the first C++ compilers … During the
translation a lot of extra variables and macro’s where inserted, e.g.
in order to generate unique function names for each method and function.
It is not completely impossible to do this by hand of course, but why
would you?

To have cleaner, safer, and more easily understood code. I wrote a lot of
object oriented C code both before and after C++ became available. It wasn’t
fully OO, just enough to make the code as robust as I wanted it to be.

These days I write mostly in C, and use C++ whenever the project benefits from
being more completely object oriented. C++ or C# tend to be overkill for some
projects, especially embedded systems work.

JeffOn Monday 16 February 2009 07:55, W.Boeke wrote:

Yeah, i manually edited the configure file to change /usr to
/boot/common and added the lrint function as you suggested. By the
way it was also needed in the make-waves.cpp file as well. The demos
run ok on Haiku, although it’s leaving traces of the cursor behind,
but that’s more a Haiku issue i think.
Nice work, looking forward to more.
-scottmcOn Mon, Feb 16, 2009 at 12:26 PM, W.Boeke <w.boeke at chello.nl> wrote:

scott mc wrote:

On Haiku we expect to see it in /boot/common/lib and /boot/common/share
Perhaps enable PREFIX, we normally pass --prefix=/boot/common to
./configure and all is taken care of there

Hi Scott,

Would you mind to modify the configure script yourself? Later on it will
be adepted like you suggested. So instead of the line:

FONTPATH=find /usr/share/fonts -name FreeSans.ttf

you write:

FONTPATH=find /boot/common -name FreeSans.ttf

Wouter Boeke


I’m sorry to disagree with you. The difference is between “compile-time
typechecking” and “run-time typechecking”. The former can only be done
in a OO language featuring function-overloading and virtual functions.

This is true, but to be pedantic, that’s just getting the compiler to do work
you could do manually.

That’s not pedantry. I don’t know what that is, but if you believe
that is a valid argument for any reason, how exactly do you justify
not writing your software as machine code bit by bit?

And about that translating to C by the first C++ compilers … During the
translation a lot of extra variables and macro’s where inserted, e.g.
in order to generate unique function names for each method and function.
It is not completely impossible to do this by hand of course, but why
would you?

To have cleaner, safer, and more easily understood code. I wrote a lot of
object oriented C code both before and after C++ became available. It wasn’t
fully OO, just enough to make the code as robust as I wanted it to be.

I believe doing more things “by hand” neither makes your project
cleaner, nor safer, nor necessarily more easily understood. If a
necessary action could be an implicit action of your code, doing it
"by hand" does not make it cleaner, it makes it more cluttered.
Writing more code, and more complex code, does not make your code
safer, it makes it more error prone and dangerous. Your code might
be more easily understood, but only if we regard the implicit actions
of non-“by hand” code (implicit actions provided by your programming
framework: language, libs, runtime, SDK, etc.) to be more challenging
to comprehend than the code itself. This is sometimes the case: some
programming languages and SDKs are very complex, convoluted, or
difficult to understand, but I don’t think anyone would argue that is
the case when comparing ML to C (if anything, C is the more convoluted
one, due to things like side-effects, type casts, and pointer
arithmetic.)

These days I write mostly in C, and use C++ whenever the project benefits from
being more completely object oriented. C++ or C# tend to be overkill for some
projects, especially embedded systems work.

I agree, I enjoy using C more than C++, but only because of how many
times I’ve been stung by the vile temptress of template programming!

When my performance bottleneck is in the programmer, I choose to use
Python or Javascript in place of C or C++.On Mon, Feb 16, 2009 at 2:26 PM, Jeff Post <j_post at pacbell.net> wrote:

On Monday 16 February 2009 07:55, W.Boeke wrote:


http://codebad.com/