[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KSpread selections
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-06-08 12:27:13
[Download RAW message or body]

John,

sorry my answer time got lost somehow. Sorry, this is KMails fault (I'm using 
cvs head).

I'm fine with your change to dcop, so upload it. 
Sidenote: Is the new solution generic enough to handle when we later move the 
seleciton to an own class?

In principle you are right, we shouldn't change dcop as long as we are in a 
normal release cycle. But I doubt that the former KSpread was used very 
intensively, especially all the dcop funtionality and the changes to the dcop 
interface should be easy to adapt I assume.

So document it (we still need a change log for such changes!) and upload it.

Remark:
After 1.2 release, we won't be able to change existing dcop functions for 
quite some time.

Philipp


Am Freitag, 7. Juni 2002 23:11 schrieb John Dailey:
> Hmm....I'm not getting a response -- maybe I didn't explain very well, or
> maybe no one thinks it is a problem  :-)
>
> The issue in my mind is that by moving the 'current selection' information
> to the KSpreadView, the scripting interfaces in KSpreadTableIface.cc cannot
> be used which means existing scripts suddenly won't work.  Does anyone see
> a way around this?  If not than this should definitely go in as soon as
> possible to affect the least number of people.
>
> I'll go ahead and commit this weekend if no one objects.
>
> -John
>
> On Wednesday 05 June 2002 09:49 pm, John Dailey wrote:
> > I'm having a problem that hopefully I can get some input on here.
> >
> > I'm working on fixing KSpread so that the current selection is part of
> > the view, not the table.  This is why multiple views of a kspread file
> > are completely useless right now.  I'm almost done except for updating
> > the DCOP interfaces.  I can't find any way to keep backwards
> > compatability in KSpreadTableIface.  There's no way to reach a view from
> > the table -- and rightly so since there may be any number of views to the
> > data and we probably are only wanting to update one certain view's
> > selection.
> >
> > Any ideas?  Or did I make the problem clear?  Just dropping the selection
> > funcitons from the table would cause major problems in any script because
> > now the selection information is passed as a parameter to nearly every
> > table operation.
> >
> > John
> > _______________________________________________
> > koffice-devel mailing list
> > koffice-devel@mail.kde.org
> > http://mail.kde.org/mailman/listinfo/koffice-devel
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]