ANNOUNCE: ParaGUI 1.0 final

SDL Development
#1

I’m proud to announce the final version of ParaGUI.

About ParaGUI:
ParaGUI is a high-level crosssplatfrom application framework and GUI
library. It is mainly based on the Simple DirectMedia Layer (SDL).
ParaGUI is targeted on crossplatform multimedia applications and
embedded devices operating on framebuffer displays.

It can be compiled on various platforms
(Linux, Win32, BeOS, MacOS X, …).

Highlights of the library:

  • published under LGPL
  • straight forward C++ class-design
  • XML configuration of the style engine
  • XML widget layout loader
  • transparent usage of compressed file archives
  • asynchronous messagehandling (messageposts between objects)
  • support for non-modal overlapping widgets
    (windows inside of ParaGUI)
  • highly customizable widgets
    (background gradients, background images, transparency, colors,
    fonts)
  • many standard widgets already implemented
    (buttons, labels, scrollbars, progressbars, windows…)
  • create your own custom widgets
    (subclass existing widgets)
  • Python support

History:
I’ve been developing WindowsNT based applications for a couple of years.

To get rid of all the dll-versions-mfc-internet-explorer crap I was
looking for alternative platforms and operating systems.
Finally I found SDL and was amazed about the flexibility and speed. One
thing missing to shift development to that new platform was the lack of
a widgetset that would meet my requirements.

So I started to implement some widgets utilizing SDL in Spring 2000.

After about 6 month of development I decided to follow the spirit of the
open source community and released the first version in August 200 under
the LGPL.

But it wasn’t the big success I hoped it would be. It has been a
constant struggle to push and advertise the project. I was flamed for
releasing the lib under LGPL (people wanted an GPL version). I was
flamed for writing ParaGUI in C++ (these guys think plain C is the
better object oriented language). Many guys from other companies
promised to use the library in commercial projects and will contribute
code (mainly nothing happened, except some really great contributions).

Sometimes it was really hard. Sometimes I really freaked out (nowadays i
see things much clearer).
But i will continue pushing the project to the limits.
:))

Credits:

Special thanks go to Sam Lantinga and the SDL community for the great
SDL library.
David Hedbor :
GCC 3.0/Win32 testing
VisualC++ workspaces
bug fixes
C++ standards checking
SDL_rotozoom integration

Marek Habersack :
PG_PopupMenu
STLport integration

Ales Teska <ales.teska at dbinvest.cz>:
new freetype font rendering
XML layout loader

Jaroslav Vozab :
PG_RichEdit, PG_WidgetListEx
new text rendering

Antonin Hildebrand :
Win32 testing
thanks for PacWars2

Mike Dunstion :
PG_SpinnerBox
first version of zipped themes

Michael Moerz <aon.912411198 at aon.at>:
Debian packaging

Jacek Poplawski - OpenGL ideas
Donald Molaro - bug fixes

SDL_rotozoom by A. Schiffler .
Reworked to fit into the ParaGUI framework by David Hedbor
.

PhysicsFS http://icculus.org/physfs/ is copyrighted by Ryan C. Gordon
under the LGPL.

Thanks to many people providing patches, fixes & ideas:

Michael Bartl
Alan Carr
Alexander Opitz
Roger D. Vargas
Brian T. Crowder
Oliver Lietz
Henrik Edwards
Paolo Ciccone
David Hunt
Jens Rieks
Dave Robillard
Ray Kelm
Francis Irving
Pete Shinners
Franck Guillaud

Sorry if I forgot anyone :))

Links:

Homepage:
http://www.paragui.org

Source tarball:
ftp://ftp.bms-austria.com/pub/paragui/release/paragui-1.0.0.tar.gz

HTML Documentation & Tutorials:
ftp://ftp.bms-austria.com/pub/paragui/release/paragui-doc-1.0.0.tar.gz

PDF Reference manual:
ftp://ftp.bms-austria.com/pub/paragui/release/paragui-refman-1.0.0.pdf.gz

Binaries:
ftp://ftp.bms-austria.com/pub/paragui/binaries/1.0.0/

Currently there are binaries for Mandrake 8 and Win32 available.
Contributions for other platforms and operating systems are welcome and
wanted.

Thanks to all of you guys.

Alex

#2

flamed for writing ParaGUI in C++ (these guys think plain C is the
better object oriented language). Many guys from other companies

well, some people just like coding in C, and it is indeed possible to work mostly object-
oriented.

Just a pity that I cannot use your library (and many other C++ libraries) in my projects
(sigh), no matter how great a job you did.

It is very easy to wrap a well-written C API in C++ classes efficiently, the other way just
does not work.

Regards,

Carsten

#3

It is very easy to wrap a well-written C API in C++ classes efficiently, the
other way just
does not work.

It depends, I know some implementations where this works well. The problem is
you need a c++ compiler to creaste the wrappers.

Florian

#4

Es schrieb Carsten Burstedde:

flamed for writing ParaGUI in C++ (these guys think plain C is the
better object oriented language). Many guys from other companies

well, some people just like coding in C, and it is indeed possible to work mostly object-
oriented.

Just a pity that I cannot use your library (and many other C++ libraries) in my projects
(sigh), no matter how great a job you did.

It is very easy to wrap a well-written C API in C++ classes efficiently, the other way just
does not work.

not true.
I know some projects that export a “C” API of their project being
implemented in C++ - the difference is the name-mangling, which
you can switch off in your C++ compiler using [extern “C”] with
a global function. Therefore:

// myWindow.h

#ifdef __cplusplus
#define CLINKAGE extern "C"
class MyWindow …
#else
#define CLINKAGE
typedef struct MyWindow MyWindow;
#endif

CLINKAGE myWindow* new_MyWindow (const otherWindow* parent);

//myWindow.cpp

extern “C” struct MyWindow* new_MyWindow (const otherWindow* parent)
{ return new myWindow(parent); }

But even that it is possible, it is not a smooth thing to
be done - you can not add new classes, and the linker
must be able to link C-derived objects with C+±derived
objects, and the system laoder must be able to load such
a mixed beast with correctly initializing static constructors
in C++.

In a way you could use the difference to enforce a data/view
separation - implement gui elements in C++ in a different
file than the behaviour, which is plain C.

That said, I prefer C implementations since they have less
overhead, and where not that much of extra stuff gets
compiled that no one needs - in parts, I want to have
control. And I was not amazed about the discussions lately
on the KDE sites when it was detected that each c++
program did get a copy of the data-portion of of the
kdelibs since the virtual tables where detected as modifiable,
so that twenty programs get each the same data-portion of
270k summing up to 5.2 gigabyte, just because of c++ not
doing best when used for shared library. So in a way: it is
possible to write library code in C++, and export a C API
from it, but the existance of a leightweight C API should
not confuse that the library may still be heavy on the
scale of system requirements. … and therefore, I don’t
recommend to implement libraries in C++ either.On the other hand, Alexander is right, since gui elements are implicitly object-oriented, and the support of the language makes for less programming tricks which would otherwise lead to more bugs, and which make it tricky to get at a new object class - I know it since I wrote
a new gtk class for my projects, and it was not easy.

cheers,
– guido http://freespace.sf.net/guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)

#5

I know some projects that export a “C” API of their project being
implemented in C++ - the difference is the name-mangling, which
you can switch off in your C++ compiler using [extern “C”] with
a global function.

thanks Guido for code example and discussion. Maybe I should try these C/C++ bindings
some time to see it working.

I basically agree with everything. (I think that for libraries C should be the norm and C++
the exception. And I modified several GTK widgets myself and saw that it is not easy.)

Regards,

Carsten