Re: high level application frameworkl

[Dirk Koopman <djk tobit co uk>]

On Tue, 2006-07-25 at 09:04 +1200, Grant McLean wrote:
> On Mon, 2006-07-24 at 18:31 +0100, Dirk Koopman wrote:
> > Fancy GUI widget drawing programs are not required.
> >
> > Is there such a thing out there for Gtk-Perl or do I have to go and
> > write (another) one?
> >
> > For the absence of any doubt at all: glade is exactly *not* what I want
> > or require. To do anything real seems to require far too much writing
> > and clicking. 
>
> Before you write off glade completely, consider the components:
>
>  1. Glade the GUI - which you apparently dislike
>  2. .glade - the XML file format which contains form definitions
>  3. Gtk2::GladeXML - the library which reads .glade files, instantiates
>     the relevant widgets and connects them up to the appropriate code
>
> > From your description, it sounds like you're going to need at least a
> file format and a library for instantiating forms from the files.  So
> perhaps the only bit you're missing is a tool for creating form
> definitions in a way that works for you and generates .glade files.

I have no particular problem with glade for the purposes outlined above
except that, as a program, it is working at the Gtk widget level which
is at least one level below which I am interested. It solves the wrong
problem (at least for my level of understanding). I don't believe that I
will need new Gtk widgets, as such, either. 

It may well be that be that an xml format will get used that may look,
at least superficially, like .glade. Except that it will be contain far
less information and (probably) no callback info or other glue. 

The problem is that I suspect I need far fewer actual types of Gtk
widget than is currently available, but the ones I do need will be
strung together in much larger numbers (ie packing boxes, lots of labels
and entry fields and some framing and/or decoration). 

It should also be made clear that these programs are not generally the
"one screen + myriad popup dialog" style of program that most GUI things
seem to be. These are much more "workflow" oriented. They tend to follow
a process from dialog to dialog (each with several entries)
sequentially. They also need to be keyboard and not mouse driven. The
mouse may be used for error handling or exceptions but otherwise takes
no part in the normal workflow. 

But I am willing to be educated and shown the errors of my ways...

Dirk