[Circle-dev] Widget trees for frontend screen layout

Paul LeoNerd Evans leonerd at leonerd.org.uk
Mon Jun 1 18:44:41 BST 2009


On Mon, Jun 01, 2009 at 10:24:19AM -0400, Philip Kovac wrote:
> > If it provides it in full, then every class down the heirarchy
> > needs to be updated whenever a base class gains a new widget. Whereas,
> > taking is superclass and modifying could be difficult in general; hard to
> > see how exactly it could know the bits to remove/replace, or places to
> > insert new pieces, in a generic way that actually copes with superclasses
> > being updated around it.
> 
> 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.

> > Neither of these approaches take into account the Session, of course.
> > Perhaps the object should just ask the Session to build a widget tree for
> > its type. The Session would therefore need a complete library of trees
> > for every type known in the Circle BE. This would provide delegation of
> > onscreen layout per Session type, but means the Session has to be fully
> > aware of all the objects.
> 
> I think this is sensible. Session types should be aware of what types
> of windows they have anyway.

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.

> > Plus, none of these ideas yet take into account that onscreen layout of
> > an item might vary per client configuration - do you want the nicklist
> > displayed in a channel window, or not, for example..?
> >
> Provide a human readable name for them, and then there could be a
> 'view' menu for each page which configures all channel windows to
> hide/show items from the list of these names.

Well, that solves simply show/hide style decisions. I was thinking
perhaps there may be some cases where layout needs to be modified or
changed based on user prefs. But perhaps that's a: a decision for the
Session, and b: us getting ahead of ourselves.. Walk before run, and all
that...

-- 
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/20090601/6f607484/attachment.pgp>


More information about the Circle-dev mailing list