gda-report's DTD and glade stuff

["David T. Bath" <bathd edipost auspost com au>]

Me:
> > > > > However, the more I think about this, the more I think that looking at
> > > > > glade, libglade and libxml is a good idea...
Others:
> > > > I think as you, this should
> > > > be the best option to implement the Report viewer and of course the
> > > > Report designer.
> > > >
> > > but, I don't understand why you want libglade for.
> > Well, i think that if we use libglade to show the report, we colud do things
> > like searching, etc.
> but, how are you going to print a libglade form?
Me (clarifying):
  I was not saying that glade et alii are the tools to use, merely that
its
  concept of widget packing, storage of the UI in XML, allowing for
binding
  a ***different layout, same elements****** at runtime, and "rendering"
  into multiple languages is pretty neat.

  I may be wrong-headed here, but I am imagining a programmer wanting to
  write a report specification in the XML we are currently thrashing
over
  the DTD for.  Should the code-cutter defining the logic of 
  database->report_elements and grouping have to worry about what
happens
  when the report is rendered at run-time into different paper sizes ?
  Indeed, in such shoes, I would rather hand over a rough layout with
  spot-on logic to SOMEONE ELSE (read "someone in userland") to worry
about
  annoying things like exact placement, fontsize, colors and
non-data-related
  properties.

  It is these facilities that I wanted to draw to the attention of the
  group.  OK, so it adds another layer of processing, but I think it
  allows compartmentalization of the two problems in reporting:
  1: Retrieving the right data into the right widgets, and performing
     the appropriate calculations within details and groups.
  2: Rendering of the widgets appropriate for the output target, be they
     screen (where the widget would behave like a resizable grid) or
     print (html/xml/pdf/ps/whatever).

  Let me make an analogy, and imagine that Gnumeric had a gda interface.
  The first problem involves specifying the queries to perform, which
  cells to return the data into, calculation of groups and break points.
  On screen, these cells are capable of being resized, etc.

  But how do we PRINT the sheets inside a Gnumeric file.  Thats the
  second problem, the rendering part.

  Remember, if rendering to ps (or ASCII), hyperlinks are completely
  pointless.  If rendering to html or screen (traditional gtk program)
  then it makes sense to use hyperlinks (html/pdf) where the screen
  program uses ">>" buttons to take you to the next group, for example.

Regards to you all
David
-- 
David T. Bath bathd@edipost.auspost.com.au
+613 9204 8713 (W) 0418 316 634 (Mbl)