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

List:       koffice-devel
Subject:    Re: Emf libray
From:       Thomas Zander <zander () kde ! org>
Date:       2009-10-25 20:33:00
Message-ID: 200910252133.01708.zander () kde ! org
[Download RAW message or body]

On Sunday 25. October 2009 13.49.43 Inge Wallin wrote:
> Yesterday, I committed a library called qemf to koffice/libs, which reads
> and handles MS Extended MetaFiles.
[]

First of all, thanks Inge for writing this email. I think its a good idea to 
open the topic to the mailinglist whenever something is done that affects the 
community or the general direction of koffice :)

From the mails here I understand that the new library is currently only used 
by the shape. The goal of the shape is to allow an emf to be loaded and 
saved without loss.
Getting this shape done *now* is important for the project Inge is getting 
payed for and therefor a filter to convert the emf to native KOffice shapes is 
not on the agenda.

I have to agree with various voices that putting this in koffice libs is over-
designing things when there is only one user (the shape).
I want to add the observation that the only other user, the filter, could 
very well replace the shape altogether. If we follow the suggestion Jan made 
with a grouping shape.
Last technical point of putting it in the libs; if you look in 
koffice/libs/NAMING and read techbase for libraries (or read ebn's list of 
errors) you'll notice that there are a lot more things to prepare when you 
put these classes in a public library. Exported symbols, d-pointers, 
renaming classes etc etc etc.

There is one more pressing point that I'd like to bring up; we keep wv2 
outside of KOffice tarballs because the software freedom lawcenter put out 
an advisory on the license under which the file formats can be used. The EMF 
file format is licensed under the same license, so the decision made a long 
time ago should apply to this new code too, I don't see any reason why it 
should not apply, do you?

The suggestion of having a new shape that shows vector and text, but 
doesn't know about our vector or text editing feature still feels wrong. And 
I'm concerned with your reasons. Roundtripping sounds like a really bad 
design decision for going read-only. Did you notice that we need either a 
MSWord or Powerpoint exporter? Both of them are non existent. As your 
other motivator was speed, writing that is out of the question and thus your 
points are conflicting.

In the end, you decide what to write and how you write it. I think working 
on the filter will get you results faster, but thats your decision.

I do see a lot of people here that agree that this new library should not be 
a library in koffice/libs. Its likely a much better idea to place it as a 
subdir of your shape, making the plugin and the emf code one plugin. One 
.so file.
How about that?

Slightly off topic;
A lot of people have suggested we start to use git because we want to avoid 
importing unfinished projects into trunk. I think Boudewijn has suggested 
this various times and I fully agree.
When we last discussed this (in Amsterdam) everyone agreed this could go 
to playground and integrate when ready (after a review here on the list).
This is how plasma and amarok are doing things and it works great for them.

Now, I guess there was some miscommunication since the emf dir was 
already in playground. I'm not sure why you moved it into koffice. 
Developing things in playground works just fine, I've written some apps 
myself using only the installed headers. Works great. So what about leaving 
the shape to mature there?

How do others think about that?
-- 
Thomas Zander
_______________________________________________
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]