Re: [gtk-list] Code generation for GTK+ apps
- From: Kenneth Albanowski <kjahds kjahds com>
- To: "'gtk-list redhat com'" <gtk-list redhat com>
- Subject: Re: [gtk-list] Code generation for GTK+ apps
- Date: Wed, 19 Aug 1998 23:02:47 -0400 (EDT)
On Thu, 20 Aug 1998, O'CONNOR, Steve wrote:
> On the subject of code generation from higher level tools, the problem
> always arises where you want to be able to add tweaks to the generated
> code, but not have them clobbered when the higher level tool regenerates
> the code. Some high level tools try to solve this by allowing the tweaks
> to be defined up at the IDE layer, but the end result is usually a
> restricted development environment and a bloated binary (vis Visual
> Basic, 4GL's, etc). There is simply no substitute for loading up raw
> source code in vi or emacs and doing what has to be done.
>
> Another approach discussed here previously involves having the generator
> embedding tags in the code, and then relying on the developer to tread
> carefully when changing the generated code. This works pretty well for
> 95% of cases, but there are still some cases where you need to make
> serious hacks to the generated code and there is no simple way of
> telling the generator not to override your hacks. This scenario will be
> familiar to developers who have used VC++ and it's embedded wizards.
I'm quite pleased by the approach Borland's Delphi (And C++Builder) use.
To attempt to explain: Borland uses a somewhat baroque approach to an OO
RAD environment, with GUI objects being instantiations of classes that are
resident in the environment's library, and the GUI forms (the eqivalent of
a toplevel window widget in Gtk) being descendants of classes that are
resident in the environment's depository, with members for each object
that is part of the form. Each form has its own C++ source file,
containing the definition of the class that represents that type of form.
This means that substantial customization is possible for every type of
form in your application, but to make a descendant of a GUI-object, a
separate compilation path must be used that ends up placing the new
descendant object back in the environment's library, so it may be used as
a simple object in a form.
All GUI objects have extensive design- and run-time customization features
via "properties", a Borland-private mechanism that lets a Delphi object
class introspectively describe how members may be changed, their types,
and even special editors for these types. Since these properties export
the complete "published" interface to an object, there is no need to go
"behind their back", and thus it is rare that a descendant object type or
access to the type's protected members is needed in the normal course of
events.
The GUI objects are defined by a binary ".res" file. The user cannot
directly edit this, but that is acceptible, as the GUI designer, by
definition, can modify all the data through the property editor interface.
The only information in the user's source code that the environment needs
to keep aligned is the C++ definitions of the GUI objects, in the
declaration section of the C++ class, and the "event handlers", methods of
the form's class which can be called by GUI objects when events occurs
(These are the equivalent of signal handlers in Gtk). The environment is
only aware of these to a small degree, sufficient to tell their prototype
(so it can provide a list of compatible handlers for a specific event),
and can remove an event handler from the source (but only if it is empty,
and no GUI object refers to it. This is provided only because the
environment makes it very simple to create a blank handler that may not
really be needed.)
Anyhow, the "parsing" of the user's C++ code appears to be of a very
simple sort, but the parsed sections are very small, reasonably well
deliniated, and the environment is very quick to warn you if you do
something to break the connection.
For example, the section of the form's class definition that is parsed
looked something (vaguely, I'm writing from memory) like this:
public: // GUI objects go here -- maintained by IDE, do not edit!
TListBox * List1;
TListBox * List2;
// Handlers
void __fastcall Handler1(TObject * handlee);
public: // User added data members
// my stuff...
Basically, the idea of this is to put all of the intelligence into the
class framework and the property mechanisms, so that user code does not
need an extensive connection to the GUI objects -- one line for each
object (and some secret code buried in the form's constructor by the
compiler, to set the property values) is sufficient.
In addition, the parser they use seems to be acceptable, as it has a very
limited charter, the data it needs to parse follows a very strict (and
essentially canonical) format, and because it warns _very_ quickly if it
is unable to parse your code.
I'm not sure whether this approach would be feasible for a Gtk
environment, especially given the fact that Gtk doesn't yet have a real
(i.e., complete & sufficient) property mechanism. If (once ;-) it gets
one, this approach might be feasible, assuming people (mostly) accept
using the stock GUI objects without modification. (Once you allow a
project to contain new object classes as well as plain objects, things get
a little more complicated.)
> Those files that are radically patched will probably have to be viewed
> by the coder before being compiled.
>
> I am wondering if it is remotely feasible to do this. Is there some sort
> of threshold of change at which point a patch file becomes becomes
> useless ? If the standard patch method is not up to the job, then
> writing a custom one just for this task would be non-trivial, but doable
> none the less.
>
> If it is possible, then we can deliver a world class high level
> development environment that makes a mockery of other commercial tools.
No programmer is going to want to run a 2diff (or maybe even a 3diff) just
to change some characteristic of a GUI object, and the maintenance issues
are scary. (Imagine trying to change GUI elements of a project that is
years old, and actually having to _understand_ the code well enough to
merge the changes. Yikes.)
Frankly, Visual Basic would make a mockery of something like this. It is
_impossible_ to screw up the VB environment, or any other environment that
uses a binary format and maintains complete control over the source code.
(Or so the theory goes. In practice, I've had every version of VB eat
source code now and then, and Microsoft had to put ASCII storage back in
so that you could safely archive code without a chance of it being eaten.)
But the principle holds: an environment with complete control of the code
editor can easily maintain any strictures it likes. In fact, the original
QuickBasic (I'm not sure about modern VB) tokenized every line of code the
instant it was typed in, and the editor was showing a detokenized
representation, not the original source. _That_ technology is down-right
respectable.
--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]