koffice

SVN commit 743552 by zachmann:

o Implement copy and paste of shapes.
  With that the basis for copy and paste of shapes between different applications is done.
  It is now possible to copy a shape e.g. in kpresenter and insert it in karbon.

  This does not yet work with text shapes as there is an assert in the text shape loading
  code that checks that there is a valid KoDocument in KoOasisLoadinContext. The KoDocument
  in the KoOasisLoadingContext is not yet used in koffice 2.0. It was used in koffice 1.6 for
  loading in the KoFieldVariable to access the url of a document and some other document
  related stuff. How will this be done in koffice 2.0? Will we still need the KoDocument
  for doing that or can the KoDocument be removed from The KoOasisLoadingContext?

CCMAIL: koffice-devel <at> kde.org

 M  +9 -0      karbon/karbon_view.cc  
 M  +1 -0      kivio/src/part/kivio.rc  
 M  +1 -0      kpresenter/part/kpresenter.rc  
 M  +2 -0      libs/flake/CMakeLists.txt  
 A             libs/flake/KoShapeOdfSaveHelper.cpp   [License: LGPL (v2+)]
 A             libs/flake/KoShapeOdfSaveHelper.h   [License: LGPL (v2+)]
 A             libs/flake/KoShapePaste.cpp   [License: LGPL (v2+)]
 A             libs/flake/KoShapePaste.h   [License: LGPL (v2+)]
 M  +30 -15    libs/kopageapp/KoPAView.cpp  
 M  +4 -0      libs/kopageapp/KoPAView.h  
 M  +50 -1     plugins/defaultTools/defaulttool/DefaultTool.cpp  
 M  +11 -1     plugins/defaultTools/defaulttool/DefaultTool.h  

--- trunk/koffice/karbon/karbon_view.cc #743551:743552
 <at>  <at>  -73,6 +73,7  <at>  <at> 

Re: koffice

On Saturday 01 December 2007 12:04:19 Thorsten Zachmann wrote:
> o Implement copy and paste of shapes.
>   With that the basis for copy and paste of shapes between different
> applications is done. It is now possible to copy a shape e.g. in
> kpresenter and insert it in karbon.
>
>   This does not yet work with text shapes as there is an assert in the
> text shape loading code that checks that there is a valid KoDocument in
> KoOasisLoadinContext. The KoDocument in the KoOasisLoadingContext is
> not yet used in koffice 2.0. It was used in koffice 1.6 for loading in
> the KoFieldVariable to access the url of a document and some other
> document related stuff. How will this be done in koffice 2.0? Will we
> still need the KoDocument for doing that or can the KoDocument be
> removed from The KoOasisLoadingContext?

The variable management has been moved to the KoVariableManager, out of 
the KoDocument and a better separation of main/text libs.

Loading of variables thus theoretically needs only the manager. I say 
theoretically here since I didn't spent any time on the text-loading code 
yet. But that may change as it looks like it stalled...

Point is; any application should have the option to set its document-wide 
manager on the loading context, but a KoDocument reference is not needed 
anymore.
Note that the variable loading code probably needs some rewrite anyway as 
it now has to use the plugin-manager to find the proper variable plugin. 
Much like the shape loading works.
--

-- 
Thomas Zander

Re: koffice

Hello Thomas,

On Saturday 01 December 2007, Thomas Zander wrote:
> The variable management has been moved to the KoVariableManager, out of
> the KoDocument and a better separation of main/text libs.
>

I had a look at the KoVariableManager. I have some questions on how it works. 
If a value of a variable changes does the document need to update the 
variable or will it be updated automatically? Can you explain this e.g. for 
the current page variable when a new page is inserted?

Thorsten

Re: koffice

On Saturday 01 December 2007 13:24:24 Thorsten Zachmann wrote:
> Hello Thomas,
>
> On Saturday 01 December 2007, Thomas Zander wrote:
> > The variable management has been moved to the KoVariableManager, out
> > of the KoDocument and a better separation of main/text libs.
>
> I had a look at the KoVariableManager. I have some questions on how it
> works. If a value of a variable changes does the document need to
> update the variable or will it be updated automatically? 

In this mail when we talk about 'document' we are talking about a 
QTextDocument, just to be clear.

The api docs says;
 " A document can maintain a list of name-value pairs, which we call
  variables. 
"These initially exist solely in the variableManager as such name/value
  pairs and can be managed by setValue(), value() and remove(). When the
  user chooses to use one of these pairs in the document he can create a
  new KoNamedVariable by calling KoVariableManager::createVariable() use
  the and insert that into the document. Changing the value will lead to
  directly change the value of all variables inserted into the document."

So, using the setter on the KoVariableManager will auto-update things 
automatically, in all text documents where the variable was inserted.

> Can you 
> explain this e.g. for the current page variable when a new page is
> inserted?

SVG path support

Greetings!

The question has come up about possibly changing the way we declare the 
SVG path attribute in ODF 1.2.

Currently, we subset the SVG path attribute by not allowing relative 
commands. (In ODF 1.1, see 9.5.3 Enhanced Geometry - Path Attributes, 
the enhanced-path attribute.)

I have checked with the editor of the SVG standard and he says that so 
far as he knows, all SVG implementations support relative paths with no 
problem.

So, the question becomes should we move closer to standard SVG in the 
next version of ODF?

I have checked with OOo and there is no objection there.

Would changing to support relative commands cause any problems for KOffice?

Thanks!

Hope everyone is having a great day!

Patrick

PS: I haven't completed reviewing everywhere in ODF where we use SVG so 
if you are aware of any other places where we subset or are different 
than "standard" SVG, please give a shout.

Re: SVG path support

On Saturday 01 December 2007 20:18:40 Patrick Durusau wrote:
> Greetings!
>
> The question has come up about possibly changing the way we declare the
> SVG path attribute in ODF 1.2.
>
> Currently, we subset the SVG path attribute by not allowing relative
> commands. (In ODF 1.1, see 9.5.3 Enhanced Geometry - Path Attributes,
> the enhanced-path attribute.)
>
> I have checked with the editor of the SVG standard and he says that so
> far as he knows, all SVG implementations support relative paths with no
> problem.
>
> So, the question becomes should we move closer to standard SVG in the
> next version of ODF?
>
> I have checked with OOo and there is no objection there.
>
> Would changing to support relative commands cause any problems for KOffice?

I don't think there would be a problem for Koffice. We support the full svg 
path attribute anyway.

Ciao Jan

Re: SVG path support

Hello Patrick,

On Saturday 01 December 2007, Patrick Durusau wrote:
> Greetings!
>
> The question has come up about possibly changing the way we declare the
> SVG path attribute in ODF 1.2.

ODF supports the SVG path attribute fully see: 9.2.6 Path.

<quote>
Path Data
The syntax for the attribute svg:d is described in §8 of the Scalable Vector 
Graphics (SVG) 1.1 Specification [SVG].
</quote>

> Currently, we subset the SVG path attribute by not allowing relative
> commands. (In ODF 1.1, see 9.5.3 Enhanced Geometry - Path Attributes,
> the enhanced-path attribute.)

That is only true for Enhanced Geometry shapes. For path shapes relative 
commands are allowed.

Are you sure you not mixing two different things?

> I have checked with the editor of the SVG standard and he says that so
> far as he knows, all SVG implementations support relative paths with no
> problem.

As I said this is already in ODF.

Re: SVG path support

Thorsten,

Thorsten Zachmann wrote:
> Hello Patrick,
>
> On Saturday 01 December 2007, Patrick Durusau wrote:
>   
>> Greetings!
>>
>> The question has come up about possibly changing the way we declare the
>> SVG path attribute in ODF 1.2.
>>     
>
> ODF supports the SVG path attribute fully see: 9.2.6 Path.
>
> <quote>
> Path Data
> The syntax for the attribute svg:d is described in §8 of the Scalable Vector 
> Graphics (SVG) 1.1 Specification [SVG].
> </quote>
>
>   
>> Currently, we subset the SVG path attribute by not allowing relative
>> commands. (In ODF 1.1, see 9.5.3 Enhanced Geometry - Path Attributes,
>> the enhanced-path attribute.)
>>     
>
> That is only true for Enhanced Geometry shapes. For path shapes relative 
> commands are allowed.
>

Re: koffice

Hello Thomas,

On Saturday 01 December 2007, Thomas Zander wrote:
> On Saturday 01 December 2007 13:24:24 Thorsten Zachmann wrote:
> > Hello Thomas,
> >
> > On Saturday 01 December 2007, Thomas Zander wrote:
> > > The variable management has been moved to the KoVariableManager, out
> > > of the KoDocument and a better separation of main/text libs.
> >
> > I had a look at the KoVariableManager. I have some questions on how it
> > works. If a value of a variable changes does the document need to
> > update the variable or will it be updated automatically?
>
> In this mail when we talk about 'document' we are talking about a
> QTextDocument, just to be clear.
>
> The api docs says;
>  " A document can maintain a list of name-value pairs, which we call
>   variables.
> "These initially exist solely in the variableManager as such name/value
>   pairs and can be managed by setValue(), value() and remove(). When the
>   user chooses to use one of these pairs in the document he can create a
>   new KoNamedVariable by calling KoVariableManager::createVariable() use
>   the and insert that into the document. Changing the value will lead to
>   directly change the value of all variables inserted into the document."
>
> So, using the setter on the KoVariableManager will auto-update things
> automatically, in all text documents where the variable was inserted.
>

Re: Resource data in libs/resources

On Wednesday 21. November 2007 22:30:59 jaham wrote:
> I sent it to the koffice <at> kde.org list first by mistake, 
I replied there ;)

> but here is another 
> go:
>
> I just had a short discussion with Sven on IRC about moving the resource
> data like patterns and gradients from the apps directories into the
> resources lib in libs/resources. As we now have a common/shared
>  infrastructure for dealing with resources we think that would make sense.
> And there are other libs containing data already, i.e. pigment with some
> solor profiles and kotext with hyphen dictionaries.
> Is there anything we do not think of, that pervents moving the data?

I did the work this morning.  /koffice/shapes is no more.

--

-- 
Thomas Zander

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