On Wed, Jan 23, 2002 at 03:32:28AM +0900, Sean Russell wrote:
> > They all keep the interface code in a separate file, and are designed
> > so that one just has to require a different file to get a different
> > interface.  In a way, this is also about writing an abstraction layer,
> > but you do it on a per-program basis, and then implement the interface
> > based on that layer.
> I've thought about this, but in my experience, the UI code can take as many 
> lines of code (or more) than the rest of the app, so aren't you writing the 
> same app three times?  Or do you have a way of doing it that avoids this?

The GTK code in the instant messaging system is 135 lines out of 465.
I *might* have some way to accomplish this somewhere real deep in the
subconscious, but if you're curious, having a look at the source might
be a better bet than waiting for it to come up. :-)

Admittedly all applications I mentioned are small, I have no
experience of how this can apply to larger ones.

BTW, I'd like to put this code online without abusing the sourceforge
account which is for another purpose.  Does anyone know of a
bannerless free space provider which doesn't frown upon non-html
files?  (I'm also interested in this for a testing repository of
rpkg-packaged modules.)

> > What about a meta-language to describe interfaces (much like Glade
> > uses XML, though Glade is limited to GTK) and then have a program
> > produce specific code for the various toolkits?
> Another good idea, but then you're forcing someone to basically learn a new 
> language (XML, admittedly not difficult) and API, rather than just
> an API.  

It might be a good bargain versus learning many different APIs.

> I also have my doubts as to how much you can pull out the logic of the XML 
> description; XUL, for example, has a lot of logic embedded in the UI 
> description file, where it doesn't belong.

Sorry, I know XUL in concept but not in implementation.  Could you
please quote a small example of what embedded in the description file?
 
> > This way we wouldn't need Yet Another Library and people could use the
> > toolkit they like most.
> They'll still neet Yet Another Library, won't they?  For the Glade-ish 
> management?

No, because there is no Glade-ish management.  (I should not have made
that comparison, I see it is misleading.)

- The developer writes the interface description in a certain meta
language.

- A processor program groks the file containing the interface
description and spits out several files containing plain Ruby code.

- Each of this files will draw an interface the usual way, either in
GTK, in QT, in Tk or whatever.  Interfaces are wrapped in a way that
lets external code access them uniformly.

- The application ships with all of these interfaces.

- The end user gets the application with all the interfaces and
chooses which one to use (or leaves it to a default, such as Windows
widgets on Windows platform).

Yes, there is still the issue of a common subset among graphic
toolkits [*] but not the one of losing potential end users because
they won't download the X or Y or Z toolkit.


[*] I see a hope of minimizing that, if a concept of necessary
features versus enhancement ones is adopted.  For example, a necessary
feature is that a button must have a label, and all selected toolkits
must have that feature.  One of enhancement is that button label can
be set in bold or italic: in that case, styles would be generated only
where available and the processor would not complain.


Massimiliano