[Circle-dev] Widget trees for frontend screen layout

[Paul LeoNerd Evans]

On Mon, Jun 01, 2009 at 06:44:41PM +0100, Paul LeoNerd Evans wrote:
> > I think it'd be more suitable to just construct the tree individually
> > rather than having subclasses. In theory they'd have relatively little
> > in common anyway aside from a few fixed fields, which you may want to
> > have in very different locations.
> 
> That's a fair point. Perhaps easier just to recreate the tree for each
> object type individually instead of worrying about merging with its
> parent ones.
...
> So it looks like each Session type (right now just officially have a GTK
> one, though unofficially there's the growing-stale-lately Tickit-based
> terminal one) will do it.
> 
> I'm getting odd flashbacks to Maui-land... ;) Perhaps some ideas we can
> steal^Wliberate from there.

Some further questions on a more specific nature:

How exactly will this widget tree be represented, both in terms of the
initial on-disk layout, in-BE, and over the wire?

In Maui we used an XML tree on disk, and just threw that out as a big
string, letting the FE parse it up as a tree. I'm not sure that's
necessarily the right approach here though.

Some sort of object tree, an arragement of Circle::Widget-derived
objects..? Say for instance:

  Circle::Widget::VBox(
    children => [
      Circle::Widget::Entry( bind => 'topic' ),
      Circle::Widget::Scroller( bind => 'displayevents' ),
      Circle::Widget::HBox(
        children => [
          Circle::Widget::Label( bind => 'nick' ),
          etc....
          ]
      ),
      Circle::Widget::Entry( bind => 'command' ),
    ]
  )

Issues like spacing and whatnot become more interesting though - how to
specificy spaces between the elements in boxes, or explain the packing
options (dirction, expand and fill)?

Also, while it suggests a nice in-memory and over-the-wire layout, it
does nothing for the initial on-disk. Perhaps the Session just has a big
blob of code, to generate these trees? Or perhaps some sort of
text-based tree structure that can be parsed somehow?

Maui also suggested the idea of Decorators.. Here we's maybe have each
Window Item actually provides a basic tree, and the Session type can
decorate it with details specific to that UI type - colours, icons,
fonts, etc.. as is appropriate.

-- 
Paul "LeoNerd" Evans

leonerd at leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.leonerd.org.uk/pipermail/circle-dev/attachments/20090603/30a6140b/attachment.pgp>