Re: Question about the "look" of GNUstep

[Nicola Pero]

> > Is there any possibility of using QT/KDE widgets, maybe via some sort
> > of binding/wrapper/bridge or whatever you want to call it?

Not easily from gnustep-gui.

I think qt/kde has objective-C bindings, and using those you can probably
do it - but mixing them with gnustep-gui might be problematic.  I'm no
expert of that anyway.


> The GNUstep UI is divided into two parts, and it's the backend that
> determines the display, I understand. A new backend could be written that
> used KDE widgets to display stuff. I got this knowledge from the question
> about the application kit being implemented in GTK in the GNUstep faq. Of
> course, if I'm wrong, don't fry me, this is just what I got from the faq!

Yes - not blaming you - I know the FAQ says that ... but I think that
explanation in the FAQ is completely wrong - very outdated and no longer
meaningful.

The gui is drawing all the 'widgets'.  The backend only provides the basic
drawing facilities to draw lines, points, images, ... 

So using a different backend will never change the look&feel of gnustep,
because the code to draw the widgets is inside gnustep-gui.

In particular, a gtk or qt backend makes *no sense*.

==

About themes, it might be worth noticing again that the WYSIWYG philosophy
of nextstep/openstep is in subtle contradiction with the idea of themes.

Without entering into details, in a WYSIWYG framework, you ask for a
button 16 points tall, with a bezeled border of 2 lines of 1 point each,
one black one white, and inside it 'OK' written starting at point (5, 4)
in the button coordinate system with a 12 point arial font in dark gray
color over a linear gradient backgroudn from gray to gray/green.  That's
precisely what happens in gnustep.  gnustep saves/restores all this
information when you save/restore a button to disk (for example, when you
use the gui builder).

In a theme framework, you ask for an unselected button displaying 'OK'.  
The size, border, graphics, font, background, foreground color of the
button is decided at runtime according to the selected theme.  It's
precisely the opposite of WYSIWYG.

In nextstep/openstep autosizing and autoalignment of widgets - which is
normal routine in gtk/qt - is not really a normal option.  Because of the
WYSIWYG attitude of the framework, in openstep you are supposed to
hardcode widgets positions and sizes - to the pixel - when you build the
GUI with your GUI builder.  Widgets are not supposed to change/accomodate
their sizes and positions dynamically in response to a change of theme or
to a change of language (as it happens in gtk/qt).  In fact, for different
languages, you have to build the whole GUI again, once per each language.  
Supporters of this idea say that autosizing/autoalignment of widgets is
always going to look ugly, and that every pixel in the GUI must be
carefully designed by a designer.  So, if you translate the application in
another language and that changes the sizes of GUI elements, you need your
graphical designer to redesign the whole GUI to take into account the new
sizes.  I suppose if you want to keep the spirit, for different themes you
would have to build the whole GUI again - once per each theme.

If you create a window with Gorm and save it, that will save a huge amount
of WYSIWYG information, including positions, sizes, fonts, colors, border
types, etc.  If we had themes, what would we do with all that WYSIWYG
information ?  That's absolutely non trivial (it's the same problem you
have when converting a nib from a foreign system to gnustep).  How do you
know if you can ignore the original window background color and display
the theme background image on the window instead, or if the original
window background color has a precise meaning ?  In most cases, the
original background/background image is the one of the original theme so
you can ignore it, but in other cases not, as in Ludovic's application
where all windows are yellow to remind you of yellow notes - you can't
discard that information.  How do you know which case is it ?  There is no
way your .gorm file will tell you.  There is no satisfactory solution to
this problem.  Gorm is a WYSIWYG GUI builder, and it's intrinsically not
theme friendly.

So - a lot of changes and thinkings are required to the framework/API to
support themes.