[Kst] a bit of dcop philosophy

Barth Netterfield netterfield at astro.utoronto.ca
Tue Jul 22 21:37:15 CEST 2003


My first impression is that the current scheme is the best.  If I understand, 
it essentially acts as a way of accessing the lists, parallel to the to the 
dialogs and command line.

Barth

On July 22, 2003 02:25 pm, George Staikos wrote:
>    I'm looking at the DCOP code here and trying to determine if I made the
> right choice.  Ideally we want to keep Kst very fast internally.  With this
> in mind, I kept the DCOP code completely separate from Kst.  It works on
> Kst essentially as though it is a black box and calls into it as necessary.
> There is another, more "pure" approach as well.  I could make each
> KstObject also be a DCOPObject.  The benefit is that we can explicitly
> expose the interface directly via DCOP.  We would have situations like
> this:
>
>    dcop kst KstIface vector <somevectorname>
>
>    This would return a DCOPRef to a vector, and then we could directly
> access it:
>
>    dcop kst <vector ref> value 0
>
>    As opposed to the current setup:
>
>    dcop kst KstIface vector <somevectorname> 0
>
>    It's much faster with the dcopref as it doesn't require lookups in the
> list each time, but it adds a bit more weight to each object.  It also gets
> messy if we want to have "nogui" support (d2asc) for KstObjects.  We would
> then have to link in dcop.
>
>    Likewise, each plot, each equation, etc would have it's own DCOP
> reference available for the user.  The exposed methods are selectable (you
> use k_dcop: to specify).
>
>    A secondary disadvantage of making each KstObject a DCOPObject is that
> we either have to safeguard all the methods for bad input, or let the user
> crash the app with bad DCOP calls.
>
>    A secondary advantage is that it might make integrating javascript
> simpler and/or make the JS interface more intuitive for the user.
>
>    There is also the option of making each of the dialogs a DCOPObject.  I
> think this is a good idea regardless, but not particularily useful -yet-.
>
>    What are your preferences?  Stay with what we have, or make each
> KstObject a DCOPObject?


More information about the Kst mailing list