Why Renaissance could be the Greatest Thing Ever

[Michael Baehr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy folks; long time no post (been travelling).

When I travel I like to dream and ponder about the Way Things Should Be.
Usually the outcome of these ponderings involves something that would be
fantastic, but that is beyond my skills as a humble beginning programmer
to implement.  This is One Of Those Things, but I thought I'd share it
with you lot.

I digested a large chunk of the "GNUStep on Win32" thread and came to 
the
conclusion that it's damn near _inevitable_ you can not create a
realistically identical GUI toolkit across three platforms.  qt has come
the closest to achieving this, but I think anyone who has used qt-mac 
can
agree that it fails. (and also, being non-free software on win32, what's
the point of using it :P )

This is why I think those fighting over whether GNUstep on Win32 should
have a native Win32 look or retain the OpenStep look are misguided.  Of
_course_ it should look native Win32.  It should use the Win32 API,
without a doubt.  Just like GNUstep on OS X, or as I like to call it,
Cocoa (wink wink), looks nice and natively Mac, and uses native Mac
widgets.  How, then, to make a cross-platform toolkit out of something
with clearly different implementations on different platforms?

The answer lies in Renaissance.

Renaissance right now just provides a way to specify interfaces in xml
files.  That's fine and dandy, and solves the whole NIB vs. gmodel 
problem
by providing one format for implementing an interface.  However, that's
not where its true strength lies.

The opportunity Renaissance provides is to revolutionarize the idea of 
GUI
composition, and make way for the first truly cross-platform GUI 
toolkit.

With XML, one could possibly start to specify interfaces not in
terms of _widgets_, but in terms of bigger design chunks.  I would refer
to these as "classes", much like the classes used in HTML ( div
class="sidebar", etc. etc.), though the terminology might be a bit
confusing, especially as these do _not_ overlap with AppKit classes the
way individual widgets do.

Let's take, for example, a simple text-editing area.  We have a toolbar
with buttons for adjusting text-size, font, style, etc, and a text view
containing the body.  On OS X, the toolbar would probably be one
contiguous layout, with the icons for the individual text controls
embedded within it.  That's the way things are expected to look on OS X.
On an X11 GNUstep platform, you'd probably have large square boxes (in a
beautiful gray tone :p).  On Win32, you'd probably have a Win32-style
toolbar that is semi-contiguous but with distinctions between individual
tool buttons.  All of these toolbars would likely be of different
sizes, too, meaning that the layout of the whole area would differ by
platform.  Let's say, just for the hell of it, that on OS X the ideal
location for the text area would be to the right of the toolbar, and 
that
on Win32 and *NIX it would be below.

We now have a chunk of design that's clearly implemented differently on
different platforms.  Should we expect our programmer to create three
different implementations for each platform, especially given that
something as general as "text-editing area with toolbar" is probably a
very common UI component?  Rather, we should define a UI class, as part 
of
a UI class library which comprises common components such as this. 
(Note,
I do not know XML, nor gsmarkup, so this is all pseudo-code)

<gsuiclass name="controlledtextarea">
   <impl="win32">
       <vbox>
            <htoolbar height="20%" width="90%">
                <button1 ...
            </toolbar>
            <textview height="70%" width="90%">
       </vbox></impl>
   <impl="osx">
       <hbox>
            <vtoolbar height="90%" width="30%">
                <button1 ...
            </vtoolbar>
            <textview height="90%" width="60%">
       </hbox></impl>
   <impl="x11">
       <vbox>
            <htoolbar height="40%" width="95%">
                <button1 ...
            </htoolbar>
       </vbox>
   </impl>
</gsuiclass>

Now our young Jedi programmer need only use a <controlledtextarea> in 
his
gsmarkup file, and he automatically has a design implementation with the
right proportions, shapes, and layout for each platform.  We are
essentially creating meta-widgets here.  I can imagine plenty more, and
when you really break down interface design, you see certain repeating
patterns and elements.  I give that one as a (poor) example but I'll 
leave
it up to you to think of more.  A library of them would be immensely
useful if the right Renaissance infrastructure was there to use them, 
and
I can imagine that they would become the interface-design equivalent of
code-snippets... traded, collected, and used with glee.

My aim is for it to be possible for a coder to create _one_ interface 
file
using these classes that will look proper in native Win32, X11, and OS X
guis, with the right shapes, proportions, and layout, and not need to
bother with custom-creating a NIB and two gmodels.  GNUstep, with an 
improved
version of Renaissance, is the best way to do this, IMHO.

The Renaissance project was started to solve a simple problem, but I 
feel
like it may end up giving us so much more.

Big up the GNUstep massive.

Good night.

- - Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE/7UvQEE/935L/FjcRAtnlAKDK9vLFcW7YUhB2qtk058xhJ0IdHACgjiPU
KhOMHsDuiqcjz3m4A4OQtts=
=ouSv
-----END PGP SIGNATURE-----