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

List:       koffice-devel
Subject:    Re: Specific API questions
From:       "Dr. Robert Marmorstein" <robert () narnia ! homeunix ! com>
Date:       2010-01-25 2:45:00
Message-ID: 201001242145.01631.robert () narnia ! homeunix ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> Note that I just committed a change that the dataCenterMap is removed and
> replaced by a resourceManager (formerly KoCanvasResourceProvider)
> 

This looks like a *VERY* nice API change.  I'm looking forward to playing with 
it.

> When the canvasController gets focus it is supposed to iterate over all the
> dockers added to the mainwindow and dynamic cast it to a
> KoCanvasObserver(Base), if it works then it will call setCanvas on it.
> 

Okay.  That makes sense.  I'm not sure why this wasn't happening in my code.  
I'll have to poke at it some more.

> > 2.  I would like to extend this so that the configuration elements
> For an example see  KWDocument::firePageSetupChanged
> where the page number is updated.
> I guess that somewhere in the libs/main/ there is code that alters the
> properties and it should use a similar mechanism to put those properties in
> the inlineTextObjectManager() (if it exists)
> 

Yes, I think I'd figured out I need an inlineTextObjectManager.  Figuring out 
how to get (the right) one has been the trick.  I'll look at the example you 
pointed me to, which should help.

> You likely want to get the KAction for that, which indeed requires a KoView
> instance.
> Not sure what the proper solution is, but you should use
>  KoCanvasBase::canvasWidget()
> and then repeatedly call parentWidget() on that to get to the top.
> One of those in the stack will likely correctly
>   qobject_cast<KoView*>(widget);
> so you can use that.
> 

Hmm.  More complicated than I expected, but it makes sense.  I'd tried playing 
with canvasWidget to get a KAction, but didn't realize I'd need to use 
"parentWidget" too.  

> Hope my additions help.
> Apologies for the heavy refactoring in trunk that will likely mean you need
> to change some of your code to compile again. The class renames I did
> yesterday (KoDockFactory -> KoDockFactoryBase etc) come to mind.

Not a problem.  I'm glad to see the code evolve to provide new features and 
better API for development.  I just hope I can make contributions that are 
worth the time you guys have invested helping me . . .

I've been delighted with how friendly and welcoming the koffice community is.  
Thanks so much for your help here.

Robert

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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