[Kst] a bit of dcop philosophy
staikos at kde.org
Tue Jul 22 20:25:48 CEST 2003
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
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:
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.
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
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst