"views" of reports as main window

Bill Gribble grib@gnumatic.com
Thu, 22 Mar 2001 09:48:56 -0600


Over the past few months people have floated different ideas about how
to make the Gnucash main window more information-rich, nicer to look
at, and more configurable.  I think there's a broad consensus that as
we get more and better reports, the reports are going to become more
of a central part of the user's interaction with gnucash.

Robert Merkel built a prototype of a pane-based main window that could
interactively construct a "grid" of reports.  The user had complete
control over the placement of reports in the windows, the size of the
windows, etc.  I think this was a move in the right direction, but had
a few drawbacks.  The main drawback IMO is that it takes too much
mousing to get things to look right; the underlying geometry
management is completely manual, so you have to ensure on your own
that each report has enough room for itself on the screen, etc.  Since
you could save and restore pane-set geometry, the problem is lessened,
but it's still a PITA to have to adjust the geometry by hand.

I propose that we do something more automatic and slightly less
configurable: create a new type of object called a "view" which is a
configurable collection of reports.  The "view" renders to HTML,
embedding the output of its constituent reports in itself according to
the view's rendering function.

For example, a typical "view" might be the "one column view".  The
parameter editor would basically just allow you to select a
one-dimensional ordered list of reports to be displayed in a vertical
column.  The view would just render as an HTML table with 1 column; it
might embed links or buttons at the bottom of each report output to
pop up a parameter editor for that report.  

Another typical view might be the "3 column" view, which would work
like a lot of the "My whatever" web sites; you have a skinny column on
each side and a fat one in the middle, and you can pick what content
goes in each column and in what order.  

Views would be named and saved and restored; to make this work
properly we also need to make reports namable/savable but that's not
terribly much work.  When you create a new view, you specify which of
the available types of views you want to use.

I think the "view editors" will have to be more sophisticated than the
current report parameter editors, but that just means we have to make
a custom editor dialog for each type of view and weld it onto the
scheme side with g-wrap.  There will probably only be a small number
of view types so I don't think it's a really big deal.

So then the "main window" just becomes a gtkhtml widget that is always
displaying a view or report.  There would need to be some way of doing
"content management" for the main window; Quicken does it with a
sidebar history/contents list, which would be easy enough.  Then we
would want the ability to split a view or report out of the main
window into its own window.

So what do y'all think? 

Thanks,
b.g.