gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

One addition: I have put together some example code showing some basics
of how the DBus interface might operate:
       http://bazaar.launchpad.net/~khaeru/+junk/dbus-magic/files

Run "python service.py" in one terminal, then "python client.py" in
another. Then marvel at how concise client.py is :D

Also a reply (inline below...)

On Wed, 2010-06-16 at 21:57 +0200, Karlo Jež wrote:
> On Wed, Jun 16, 2010 at 5:41 PM, Paul Natsuo Kishimoto
> <mail@xxxxxxxxxxxxxxxxxxx> wrote:
>         COMPLEX
>         
>          Tags and Tasks are subclasses of TreeNodes. The current GTK
>         UI relies
>         heavily on classes like TagTreeView, TaskTreeView (and
>         friends), which
>         in turn reference -Model classes, which in turn rely on things
>         like
>         TagStore and FilteredTree, which are subclasses of Trees and
>         contain
>         TreeNodes.
>         
>          This represents a problem because references to object
>         instances go
>         back and forth between code under GTG/core/ and GTG/gtk/. That
>         can't
>         happen once separation occurs.
>         
>         Broadly, my question is,
>         
>                Should all data *structures* involving Tasks and Tags
>         live on
>                the server side
>         
>                OR
>         
>                Should the client use classes analogous to the
>         server-side ones
>                to manipulate data structures?
>         
>         In the former case, interrogating a tree in any way (does a
>         node have
>         children, finding the root node, finding the path of a node)
>         will
>         involve a DBus call.
>         
>         In the latter case, those things can happen on the client
>         side; but a
>         mirror of the task tree needs to be maintained. I envision
>         this
>         happening by passing a chunk of text containing task IDs:
>         
>                '4d9cf2a6-1030-4ff4-8d9b-f0608f694840'
>                        '4c89e6ee-3b7a-41e7-8757-6c8d9aa33968'
>                                'c8ff728e-9754-4f48-9771-ce2277aa1011'
>                                '6ae3b560-aff1-43e8-97f2-482a73f4e3dc'
>         
>          '6b30ac23-4be3-43aa-8095-096f3d35c866'
>                        'b00a1be1-89d3-45ff-9041-4ed337bf204b'
>                                '06085441-637c-4680-ae57-29117f414487'
>                '3cbbb007-dc62-4ecc-9327-cbe5e747b22e'
>                        'de53b231-97d4-4e9a-b923-985a42f4e5c3'
>                                '292c87ae-868a-4f05-b895-c6ddfbbde08a'
>         
>         ...which encodes hierarchy. The client will manipulate a tree
>         of strings
>         (lightweight) and obtain & query the a DBus proxy for each
>         Task only
>         when necessary. One downside here is that there will need to
>         be some
>         mechanism for keeping the mirror up to date.
>         
>          Does anyone have a preference here?
> 
> I'm not sure if this method offers benefits over the current model in
> which child and parent ids are part of task information.
> You have to parse the task tree either way.
> If there is manipulation of the tree, that means that tree structure
> has changed on the client side - which I think should immediately be
> reflected on the server.
> 
> What could be added are some return/add parent/child calls to the dbus
> api which could simplify tree operations.

  The issue is that the current model (UI-side and backend-side code
intertwined) can't be maintained if I am to finish my project :) So
something has to replace it, I'm just comparing alternatives.

  I agree re: manipulation. However, the performance of the UI is
probably most strongly affected by reading task and tag trees to
populate the gtk.TreeView derivatives. An interface that would doom
these to always being slow would not be a good idea.

-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part