Re: koffice/plugins/pictureshape

On Thursday 30 July 2009 09:02:03 Thomas Zander wrote:
> On Thursday 30 July 2009 09:50:49 ext Thorsten Zachmann wrote:
> > > use the flake shape manager, it fixes your problem by correctly
> > > propagating the shapes request to repaint.
> >
> > That is not possible for a method that returns a pixmap.
>
> Then what about you use a flake canvas for your slide sorter instead?
> No pixmap generation needed.
>
> > The same problem
> > also happens during printing so we need a fix for that usecase.
>
> Also on my todo; I'll make the KoShape::waitUntilReady() concept for that,
> though.  Which you could use too, I guess.

Any idea when that will be implemented? It seems the svg import of pattern 
backgrounds is broken atm. 

Ciao Jan

Review Request: Initial instance for KoTextEditor

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1212/
-----------------------------------------------------------

Review request for KOffice.

Summary
-------

This is an initial instance of the KoTextEditor. I am going on holiday tomorrow and will probably not be able
to connect to Internet. I'll be able to code, but not to sync or get feedback. I'd be grateful if some of you
could try this out as I'd like it to be part of 2.1. It is not only a fix for a bug we have (scripts will mess our
undo/redo), but is also a ground building brick for further change tracking. Basically, the
KoTextEditor is supposed to supersede the KoTextSelectionHandler. It does the same thing but handle the
undo/redo mechanism (as opposed to before where the undo/redo was handled by the tool). So if some of you
could give it a spin in the next couple of weeks and give me feed-back when I am back from holiday, I'd
appreciate. In order for the undo/redo in TextShapes to wor
 k in any given app, the KoDocument::undoStack() needs to be populated in the dataCenterMap. I can take care
of this, but so far it is only done for KWord.

Thanks for your help,

Pierre

Diffs
-----

  trunk/koffice/kword/part/KWDocument.cpp 1005434 

Re: koffice/plugins/pictureshape

On Saturday 1. August 2009 16.00.57 ext jaham <at> gmx.net wrote:
> > Also on my todo; I'll make the KoShape::waitUntilReady() concept for
> > that, though.  Which you could use too, I guess.
>
> Any idea when that will be implemented? It seems the svg import of pattern
> backgrounds is broken atm.

I'm sorry to admit I don't know how to test that or where this code is 
implemented.
Can you give me some hints so I can look at this breakage?
--

-- 
Thomas Zander

[patch] Extra methods for KoGenStyles useful for debugging

Dear All,

For review: 
Extra methods for KoGenStyles useful for debugging purposes, when we have to 
insert some styles expressed in raw XML generated elsewhere.

Separate methods for office:styles, office:master-styles, office:automatic-
styles implemented.

Without this, implementing/testing new custom filters would take much more 
energy.

--

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 http://www.linkedin.com/in/jstaniek

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

de-qt3-ing koffice

Hi,

I'm committing a bunch of attempts at reducing our reliance on Qt3 things. 
I've quite carefully tested whether these commits didn't cause regressions in, 
for instance, the filters, but don't hesitate to yell at me if you found 
anything that's broken. 

I intend to go on with this janitorial work until I've removed all qt3/kde3 
deps from koffice, except for kexi, because jaroslaw is working on a rewrite 
anyway. But please don't use qt3-compat classes in new places 

--

-- 
Boudewijn Rempt | http://www.valdyas.org

Re: [patch] Extra methods for KoGenStyles useful for debugging

Hello,

> For review:
> Extra methods for KoGenStyles useful for debugging purposes, when we have
> to insert some styles expressed in raw XML generated elsewhere.
>
> Separate methods for office:styles, office:master-styles, office:automatic-
> styles implemented.
>
> Without this, implementing/testing new custom filters would take much more
> energy.

The patch looks good but I think it can be refactored a bit to not duplicate 
the same code, but instead use a function like

+void KoGenStyles::addRawOdfDocumentStyles(const QByteArray& xml, QByteArray& 
styles)
+{
+    if (xml.isEmpty())
+        return;
+    if (!styles.isEmpty() && !styles.endsWith('\n') && !xml.startsWith('\n')) 
{
+        styles.append('\n');
+    }
+    styles.append(xml);
+}

Also I would unify the two different calls 

+    QByteArray &target = d->rawOdfAutomaticStyles(stylesDotXml);

common config dialogs

Hello,

I'm working on extracting common config dialog pages for common usage into 
libs. As the dialogs depend on komain. I would prefer to not put them not into 
widgets as widgets does not depend on anything in komain. 

So what do you think about about putting into komain/config or komain/widgets?

Thorsten

Re: koffice/plugins/pictureshape

On Monday 03 August 2009 17:21:04 Thomas Zander wrote:
> On Saturday 1. August 2009 16.00.57 ext jaham <at> gmx.net wrote:
> > > Also on my todo; I'll make the KoShape::waitUntilReady() concept for
> > > that, though.  Which you could use too, I guess.
> >
> > Any idea when that will be implemented? It seems the svg import of
> > pattern backgrounds is broken atm.
>
> I'm sorry to admit I don't know how to test that or where this code is
> implemented.
> Can you give me some hints so I can look at this breakage?

Sure it is in the SvgParser class in filters/karbon/svg/ starting lines 
1373-1381. The code deals with svg patterns which can be anything from an 
image element, vector shapes or groups of shapes. These are parsed/created and 
then drawn to an image which is then used for a KoShapePatternBackground. The 
problem is when I draw the shapes to the image, the picture shape is not 
painted when ::paint is called, but the painting is deferred. Which is bad 
because I do delete these shapes that constitute the pattern after drawing. So 
the picture shape is deleted before it attempts to paint, which obviously 
crashes.
So to test you just have to create a shape with a pattern fill, save it to svg 
and then try loading that.

Ciao Jan

Re: common config dialogs

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

Re: common config dialogs

On Tue, 4 Aug 2009, Cyrille Berger wrote:

> On Monday 03 August 2009, Thorsten Zachmann wrote:
> > Hello,
> >
> > I'm working on extracting common config dialog pages for common usage into
> > libs. As the dialogs depend on komain. I would prefer to not put them not
> > into widgets as widgets does not depend on anything in komain.
> >
> > So what do you think about about putting into komain/config or
> > komain/widgets?
> It could be worth investigating the use of kcm for our config (and kcm doesn't 
> mean systemsettings ;) ), that's the solution used in kdevelop. That way the 
> config pages would be a plugin, and we would just need a page-based dialog in 
> lib/widgets to show the config we want.  
> 
Sounds like a good idea, too. Though that doesn't preclude first sharing the 
existing dialog pages, we can then easily factor them out into the plugins dir.

Boudewijn