[Kst] a bit of dcop philosophy
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.
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
> 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.
> 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