🚀 go-pugleaf

In article <6udm2m$cij@ics.com> dbl@jackal.ics.com "David B. Lewis" writes:
> |> has written, so if the UI is changed, the programmer's code gets
> |> overwritten. Sometimes the tool attempts to get round this problem
> |> in a clumsy way with comments, eg:
> 
> Tools that do this properly re-read the changes and then export them 
> unchanged.

Yes, and tools that do this not-properly *try* to re-read the changes
and fail.
 
> |> IMO this is, at best, ugly. The idea behind putting the UI code
> |> and the functionality code in separate classes is to remove this
> |> problem.
> 
> True, but you'd really have to come up with a reasonable way to have the
> classes interact in order to make this effective.

Fortunately OO languages have inheritance. One possibility might be
to have a UICode class, a FunctionCode class, and use multiple 
inheritance to create a DoItAll class that inherits from both; of
course, this won't work in all languages.
 
> |> C++/Qt, C++/GTK--, C/Motif, Java/awt, Python/tkinter, etc. Indeed,
> |> backends could be written that target other platforms, such as
> 
> Having different back-ends works only if they have enough in common so that
> the "front-end" (i.e. the part that the user manipulates) makes sense.  That
> is, it doesn't do much good to output Java/AWT code unless the objects that
> are being manipulated resemble the AWT objects. I don't think you want to
> limit yourself to some universal interface and then have to deal with the
> least common denominator; if the RAD tool is actually good at building
> interfaces, then it should be used to deal with the hard details of a
> particular toolkit.

I think that two approaches could be done here:

(1) the simple approach. The GUI builder only uses widgets for each
backend that are implemented in that backend. This means that any
UI that you write for the GUI builder will only be portable to other
backends if you make sure you use widgets that are common to all
the backends you intend to use.

(Perhaps there could be a compiler switch so it gives a warning if
you use non-portable widgets).

(2) the complex approach. The GUI builder creates a set of additional
widgets, so that all the backends support a very comprehensive range
of widgets. The problem with this approach is that it would take
a lot of work.
 
> |> Does anything like this currently exist for Linux?
> 
> There are several tools available for Linux. One tool that has been demo'ed
> on Linux but is not (yet?) being produced for it is the ICS Builder Xcessory,
> which can produce C, C++, C++/ViewKit, Ada, Java/AWT (1.1), and C/UIL code.
 

-- 
@@--Phil Hunt-----------------------------Don't fear the penguins(*)--@@ 
@@  [*] Disclaimer: this is FREE ADVICE, and is distributed in the    @@
@@  hope that it will be useful, but WITHOUT ANY WARRANTY; note also  @@
@@  that this advice may not apply if your name is Gates or Ballmer.  @@