|
»
»
Re: trunk
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: trunk
by Cyrille Berger
::
Rate this Message:
On Sunday 25 October 2009, Thomas Zander wrote:
> Oh, Inge, come on! > > A new library in koffice libs should *not* be just imported without *any* > discussion on the mailinglist. > > Can you please start working in koffice with the fact that this is a > community, a group of people that are all affected by the things you do? > > Before such a discussion is done, you can revert this commit. so far all file related library are in koffice/filters, I think qemf belong there. -- Cyrille Berger _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
|
|
Re: trunk
by Cyrille Berger
::
Rate this Message:
On Sunday 25 October 2009, Cyrille Berger wrote:
> so far all file related library are in koffice/filters, I think qemf belong > there. and that it should be renamed to koemf. -- Cyrille Berger _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
|
|
Re: trunk
by Bugzilla from zander@kde.org
::
Rate this Message:
On Sunday 25. October 2009 10.26.45 Cyrille Berger wrote:
> so far all file related library are in koffice/filters, I think qemf > belong there. Thats true, but not my point. -- Thomas Zander _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
|
|
Re: trunk
by Bugzilla from inge@lysator.liu.se
::
Rate this Message:
On Sunday 25 October 2009 10:11:26 Thomas Zander wrote:
> On Sunday 25. October 2009 00.41.35 Inge Wallin wrote: > > SVN commit 1039926 by ingwa: > > > > Move the EMF (MS Extended Metafile) library from the okular playground > > to the KOffice libraries. This is what Brad Hards, the original > > author wanted. > > > > > > > > A koffice/libs/qemf (directory) > > playground/graphics/okular/emf/emf#1039925 D > > playground/graphics/okular/emf/emf (directory) > > Oh, Inge, come on! > > A new library in koffice libs should *not* be just imported without *any* > discussion on the mailinglist. > > Can you please start working in koffice with the fact that this is a > community, a group of people that are all affected by the things you do? > > Before such a discussion is done, you can revert this commit. > We did have that discussion before the freeze. I was told that I couldn't do it before the branch but had to do it afterward so I removed it then and waited. Why didn't you say anything then if you thought that the library was wrong? And what's this about discouraging new features? The library is necessary for importing and showing EMF files and attachments. There are similar libraries under plugins/ and I would normally have put it there, but in this case it's going to be used by a plugin, and in the future also (likely) a filter. If you can suggest a better place to put it I'll be open to that, but at this point I don't see any. _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
|
|
Re: trunk
by Bugzilla from sven.langkamp@gmail.com
::
Rate this Message:
On Sun, Oct 25, 2009 at 12:58 PM, Inge Wallin <inge@...> wrote:
Form my answer to the dicussion before the freeze: I think we need a shape that does both. The shape has to load an external SVG/WMF/EMF/whatever image and save it as external image. The way it's now we would basically need a new lib for any file format, so once we want to load embedded svg files we would need a kosvg. I think there should be a vector image shape like the above that can you some sort of fiter to load different vector image formats. _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
|
|
Re: trunk
by Bugzilla from inge@lysator.liu.se
::
Rate this Message:
On Sunday 25 October 2009 13:13:51 Sven Langkamp wrote:
> On Sun, Oct 25, 2009 at 12:58 PM, Inge Wallin <inge@...> wrote: > > On Sunday 25 October 2009 10:11:26 Thomas Zander wrote: > > > On Sunday 25. October 2009 00.41.35 Inge Wallin wrote: > > > > SVN commit 1039926 by ingwa: > > > > > > > > Move the EMF (MS Extended Metafile) library from the okular > > > > playground to the KOffice libraries. This is what Brad Hards, the > > > > original author wanted. > > > > > > > > > > > > > > > > A koffice/libs/qemf (directory) > > > > playground/graphics/okular/emf/emf#1039925 D > > > > playground/graphics/okular/emf/emf (directory) > > > > > > Oh, Inge, come on! > > > > > > A new library in koffice libs should *not* be just imported without > > > *any* discussion on the mailinglist. > > > > > > Can you please start working in koffice with the fact that this is a > > > community, a group of people that are all affected by the things you > > > do? > > > > > > Before such a discussion is done, you can revert this commit. > > > > We did have that discussion before the freeze. I was told that I > > couldn't do > > it before the branch but had to do it afterward so I removed it then and > > waited. Why didn't you say anything then if you thought that the library > > was > > wrong? > > > > And what's this about discouraging new features? The library is > > necessary for > > importing and showing EMF files and attachments. There are similar > > libraries > > under plugins/ and I would normally have put it there, but in this case > > it's > > going to be used by a plugin, and in the future also (likely) a filter. > > If you can suggest a better place to put it I'll be open to that, but at > > this point I don't see any. > > Form my answer to the dicussion before the freeze: > > I think we need a shape that does both. The shape has to load an external > > SVG/WMF/EMF/whatever image and save it as external image. > > It it would make sense to store as SVG only and not save EMF (at least if > > you don't lose information). Addtionally the shape should offer an > > ungroup functionally so that it can be edited later. > > As long as the shape isn't ungrouped it's saved a seperate image, after > > ungrouping it's save inline in the odf data. > > > > The only problem with the ungrouping is that not every feature that the > > image format supports can be saved back to odf. For example you could > > have an embedded SVG image with a filter effect, ungroup it and save it > > as odg then you lose the filter effect. > > The way it's now we would basically need a new lib for any file format, so > once we want to load embedded svg files we would need a kosvg. I think > there should be a vector image shape like the above that can you some sort > of fiter to load different vector image formats. That is very true, but you mix two things: - The need for a library to handle a particular file format. I don't think that's strange at all. This library could then be used to show the file as it is (if it supports that) or to be used as a base for a converter. - The need for a unified vector shape. This shape could handle several different file formats, for instance by using the libraries. I'm not sure how the current picture shape does its thing, but I suppose that it uses for example libjpeg to handle jpeg images. _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
|
|
Re: trunk
by Bugzilla from bradh@frogmouth.net
::
Rate this Message:
On Sunday 25 October 2009 20:11:26 Thomas Zander wrote:
> On Sunday 25. October 2009 00.41.35 Inge Wallin wrote: > > SVN commit 1039926 by ingwa: > > > > Move the EMF (MS Extended Metafile) library from the okular playground > > to the KOffice libraries. This is what Brad Hards, the original > > author wanted. Just to be clear - I didn't want it to be copied into koffice because it would then diverge from the copy in playground as people started to mature what is, fundamentally, an exploration of the format in support of something that could render .snp (Snapshot, produced by Access). Where it lives in koffice (or elsewhere) doesn't worry me much. I would like to be able to share it at some potential later time should I ever get back to the snapshot renderer for Okular. Brad _______________________________________________ koffice-devel mailing list koffice-devel@... https://mail.kde.org/mailman/listinfo/koffice-devel |
| Free embeddable forum powered by Nabble | Forum Help |
