[Circle-dev] Widget trees for frontend screen layout

[Paul LeoNerd Evans]

Last time I said:

> Next up as a general interest area, unless anyone shouts objections,
> will be an attempt at "widget"-ifying the individual windows, so the
> backend can suggest UI components on them, that the frontend can display
> and lay out. Hopefully this should allow me to exorcise the last bits of
> IRC-specific code in the frontend (it currently has to know about IRC
> channels, with their topic/mode/occupants/etc...)

I'm starting to move onto this more specifically, and needing some ideas.

I think the basic structure in my head looks something like the following:

 * Any window item provides a scroller pane, and a text entry box.

 * IRC server windows further provide some connection status information
   (nick, connected? , etc...)

 * IRC channels provide topic, channel mode, occupant summary counts,
   perhaps nicklist, etc...

 etc...

These are provided as "widgets" by the backend objects, each having a
specific type that the frontend UI can deal with in some way. Backend
provides data to display to frontend, frontend sends UI interaction
information back. Namely;

 * Scrollerpane has list of events, no events come back

 * Text entry has no information (currently; [1]), sends "entered a
   line" event back

 * Status labels are simple text, no events..

 etc...

My current design problem is on how to specify a layout.. Currently the
frontend UI is hand-written for each object type (root object, IRC
server, IRC user, IRC channel), to provide a layout. For example, the IRC
channel (the most complex) looks like:

  VBox of:
    topic
    scroller
    HBox of[ myflag nick  channelmode         occupants count ]
    text entry

This little widget tree ought, I think, to be provided by the backend,
perhaps in relation to the Session (which knows the frontend type; GTK in
this case, so would be able to make decisions in general about other UI
frameworks).

My exact problem is how to provide each object's widget tree to the
frontend, including possibly any types of object provided by parent
classes. Because all the window items (currently defined, anyway... [2])
have basic scroller and text entry widgets, these will be present for any
object. So should each object type, eg.. IRC channel re-provide its
widget tree in full, or could it somehow be pieced together a class at a
time, each class building its superclass tree, then modifying for its
own needs? 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.

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.

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..?


Thoughts, as ever, appreciated to the usual address...


-----

[1]: This would give a good integration point to put things like
     commandline history and tab-complete; they become properties of the
     text entry widget.

[2]: Moving the onscreen layout into a widget tree like this would allow
     us easily to move beyond text+scroller objects. Perhaps the root
     view of an email server would be a treeview of message folders.

-- 
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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.leonerd.org.uk/pipermail/circle-dev/attachments/20090601/a3d5a6c4/attachment.pgp>