• Tristam MacDonald <swiftcoder gmail.com> Jul 13 2007
• Tomas Lindquist Olsen <tomas famolsen.dk> Jul 13 2007

Tristam MacDonald <swiftcoder gmail.com> writes:

Why, why, why would you want a GUI toolkit in the core library? What is wrong
with having a separate (possibly installed by default) GUI lib?

Phobos is already over a megabyte in most environments, and only shipped as a
static library. If I am distributing a simple command line tool, I *do not*
want another meg (and it could easily be 3 times that) of GUI junk statically
linked in. I know that dead code stripping and similar *should* remove that
excess junk, but from my experience this is not reliable.

Even if phobos/tango, etc. are shipped as dynamic libraries, they still don't
come pre-installed in most environments, necessitating that any installers
include them, so size is still a concern.

And beyond all that, OpenGL is not really a generally useful tool. With out a
full fledged GUI toolkit (with all widgets, etc.) that allows embedding OpenGL
contexts in controls, it is only really useful for games and screensavers.
Libraries such as GLFW suffer from a severe sparsity of features, as they are
only designed to support games.

Seriously, how hard is it to drop gl.d and glfw.d into your project?

Mikola Lysenko Wrote:

 Pragma Wrote:
 
 If I may ask: what is your take on how GL should be provided as a D library? 
There are any number of ways to go, 
 ranging from a full-fledged OO wrapper to a faithful port of the C headers and
interfaces and everything in between 
 (assuming you're not proposing that we just fold Derelict in with Phobos or
Tango).
 


 I think that the best strategy is to match the C interface as closely as
possible.  The problem with using higher level D specific features is that
OpenGL changes far too often for high level stuff to make much sense.  Limiting
it to C functions basically ensures that no matter what the Khronos group & co.
add, it can always be accessed directly.  This is especially true for vendor
specific extensions which are often necessary for writing high performance GL
code.
 
 Likewise, many online examples are written for C-style OpenGL code.  Porting
them to D is much easier if D matches the functionality exactly.  This ties in
pretty well with the idea that adding OpenGL support should make D more newbie
friendly.
 
 Finally, OpenGL itself isn't tied down to any specific windowing library or
platform.  If you stick to the C stuff, there is virtually no chance that you
are going to step on the toes of any windowing kit out there.
 
 However, this is also where the idea unravels a bit.  While OpenGL by itself
is wholly reasonable to support, in order for it to actually do anything you
need a host of other windowing and input functions.  One good compromise could
be adding a GLUT-style windowing kit to D, but this would incur a substantial
amount of work.  The problem is that all of the frameworks that I know of have
at least one or two pathological flaws which make them break D in unpleasant
ways.  In brief:
 
 GLUT - Requires C-style function pointers for various window functions.  This
typically breaks with D code, and requires a bunch of messy casting.  At the
very minimal you would need to wrap ~90% of the library methods in a D language
thunk.
 
 SDL - Hijacks main() with SDL_main().  This causes a lot of current D code to
break in unpleasant ways.  Also, it has a lot of bloat, such as various 2D
sprite drawing things that are pretty much irrelevant for OpenGL applications.
 
 GTK -  Far too huge.  Also requires a substantial runtime library install on
windows.
 
 Platform specific stuff (Win32, X, etc.) - In general decent usability from D,
but completely unportable.
 
 Overall, it seems like a bit of a dilemma.  Of all the systems I've seen
probably the best candidate is GLFW.  It is small, supports static linking, has
a consistent interface, and is widely portable.  The main drawback is that it
is good for getting a window open and not much else.  It would probably
function as a decent stand-in until someone gets a real UI library together for
D.  Even then, it could still be a nice alternative for users who don't want to
deal with a lot of extra set up hassle.
 
 -Mik

Tomas Lindquist Olsen <tomas famolsen.dk> writes:

On Fri, 13 Jul 2007 07:27:05 -0400, Tristam MacDonald wrote:

 Why, why, why would you want a GUI toolkit in the core library? What is
 wrong with having a separate (possibly installed by default) GUI lib?
 
 Phobos is already over a megabyte in most environments, and only shipped
 as a static library. If I am distributing a simple command line tool, I
 *do not* want another meg (and it could easily be 3 times that) of GUI
 junk statically linked in. I know that dead code stripping and similar
 *should* remove that excess junk, but from my experience this is not
 reliable.
 
 Even if phobos/tango, etc. are shipped as dynamic libraries, they still
 don't come pre-installed in most environments, necessitating that any
 installers include them, so size is still a concern.
 
 And beyond all that, OpenGL is not really a generally useful tool. With
 out a full fledged GUI toolkit (with all widgets, etc.) that allows
 embedding OpenGL contexts in controls, it is only really useful for games
 and screensavers. Libraries such as GLFW suffer from a severe sparsity of
 features, as they are only designed to support games.
 
 Seriously, how hard is it to drop gl.d and glfw.d into your project?
 


I must say I agree here. There are way too many things to
consider for *any* type of graphics toolkit for it to go in the
standard library IMHO.

What we really need is people to start using DSSS. And if necessary
make DSSS easier to use. That would make it really easy for anyone
to get the libraries they want.