For developers interested in KOffice

Clarence Dang | 3 Mar 2006 12:23

Re: adding a method to KoCommandHistory

On Wednesday 01 March 2006 22:14, David Faure wrote:
> On Wednesday 01 March 2006 06:14, Clarence Dang wrote:
> > On Monday 27 February 2006 01:27, Casper Boemann wrote:
> > > In order to solve a showstopper problem in krita I'm about to add a
> > > method to KoCommandHistory that returns a pointer to the present
> > > command in the undo stack. That is, the command that would be undone by
> > > the next undo().
> > >
> > > Krita will only use this to get information and will not modify the
> > > command in any way. This will not affect any other app or tool.
> > >
> > > I don't know if this is a viable longtime solution, but it does solve
> > > the krita problem and seem like a nice addition to the commandhistory
> > > interface. Comments ?
> >
> > KolourPaint has such a hack as well.  Getting undo/redo right is tricky.
>
> For selection too?

Yes.

> > OTOH, the reason there is also a KolourPaint
> > kpCommandHistory is mainly due to licensing and supporting earlier
> > versions of KDE.

Also, I couldn't subclass {K,Ko}CommandHistory to do what I wanted: amount of 
undo/redo history also bounded by estimated memory required.

> licensing? kdeui is LGPL, what's the problem?

(Continue reading)

headers

David Faure | 3 Mar 2006 13:13

Re: adding a method to KoCommandHistory

On Friday 03 March 2006 12:23, Clarence Dang wrote:
> Also, I couldn't subclass {K,Ko}CommandHistory to do what I wanted: amount of 
> undo/redo history also bounded by estimated memory required.

Interesting. Can you have a look at kcommandhistory in kdelibs trunk and suggest
a patch? The problem is that we can't just make clipCommands virtual, it needs to adjust 
a number of private member vars; we rather need clipCommands to call a virtual
method to find out how many commands to remove in both directions.

> 1. I didn't like the code esp. the way the history clipping code was written.

I agree. This is why I rewrote it all in trunk, please have a look.

> 2. It would require Makefile.am trickery to create a library to isolate the 
> LGPL {K,Ko}CommandHistory from the BSD KolourPaint.

Bah. Those are compatible and kolourpaint can't work without LGPL-kdelibs anyway.

--

-- 
David Faure, faure <at> kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

headers

Clarence Dang | 3 Mar 2006 13:25

Re: adding a method to KoCommandHistory

On Friday 03 March 2006 23:13, David Faure wrote:
> On Friday 03 March 2006 12:23, Clarence Dang wrote:
> > Also, I couldn't subclass {K,Ko}CommandHistory to do what I wanted:
> > amount of undo/redo history also bounded by estimated memory required.
>
> Interesting. Can you have a look at kcommandhistory in kdelibs trunk and
> suggest a patch? The problem is that we can't just make clipCommands
> virtual, it needs to adjust a number of private member vars; we rather need
> clipCommands to call a virtual method to find out how many commands to
> remove in both directions.

I'll add it to my TODO.  I'm trying to build KDE4 first :)

> > 2. It would require Makefile.am trickery to create a library to isolate
> > the LGPL {K,Ko}CommandHistory from the BSD KolourPaint.
>
> Bah. Those are compatible and kolourpaint can't work without LGPL-kdelibs
> anyway.

I meant that I would have to have made an extra lib instead of just linking 
directly to avoid LGPL contamination.

Clarence