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

List:       koffice-devel
Subject:    Re: Explanation on WP vs DTP modes in KWord (Re: Kde-cvs-digest request for information)
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-12-01 13:21:36
[Download RAW message or body]

(As i have not much time, I am answering to a few emails in one.)

I am not in favour of another application in KOffice, especially one where 
there would be only one developer.

We have already very few developers and we have already had the case that we 
have to close an application (Kontour) because the maintainer has been lost 
(other examples: KWord's ASCII and HTML filters before KOffice 1.1 and the 
RTF import filter before KOffice 1.2)

Out of lack of information, I thought that Scribus was more a library. Sorry 
to have misunderstood.

(It is sad that it is only GPL, because that would make the printing library 
GPL. However, in that case, we could take QT's to make something out of it.)

I am also not in favour of splitting KWord in WP and DTP. On contrary, it 
could be its strength to cover both sides. We should try to remove the modes 
(or at least to downtone them, so that they look as options that we can 
switch any time.)

This is also about the position of KWord. OpenOffice already covers WP. 
Scribus seems to cover DTP. If KWord (or KOffice) immitates one of both, we 
will have nothing new.

The sad result out of it is that we probably need to start to take care about 
PostScript generation ourself. (Sigh!)

Have a nice day/evening/night!

On Sunday 01 December 2002 00:29, Sean McGlynn wrote:
> On Saturday 30 November 2002 21:37, Dirk Schönberger wrote:
> > One of the things I absolutely don't like about the "professional" DTP
> > applications is their non-sharing attitude and their
> > non-interchangeability, i.e. all applications are specialist tools, but
> > the general useability, like common file formats,
>
> The native Scribus file format is XML based, liked any KOffice app, so that
> wouldn't be a problem.
>
> > common clipboard exchange,
>
> Scribus has a compile-time option (I think) to support drag and drop when
> running with KDE. I guess that means it uses the XDND standard. As a Qt
> app, I guess its clipboard features are similar to (or easily changeable
> to) those of KDE apps.
>
> > common clipart/graphics support,
>
> I don't think that's a problem and I'm sure Scribus would improve in this
> area if it were a KOffice app.
>
> > common GUI ..., is non-existant.
>
> Even as an existing Qt app, Scribus can look just like a KDE app (I've seen
> the piccies of it using the Keramik style :-)
> Of course, if it "were" a KDE app then that point is irrelevant.
>
> > Somehow I don't have the impression that the Scribus authors are
> > interested much in this direction. This make it rather difficult as a
> > KOffice component, at least IMHO.
>
> Got to say that I disagree with you here Dirk. From my
> (non-KOffice-developer
>
> :-) point of view, I think Scribus would fit perfectly into KOffice as a
>
> dedicated DTP component. I know there's some overlap with KWord's features,
> but I'm sure a little bit of refactoring could sort that out. Of course I
> could be totally wrong in all this; it's just my personal impression. It
> might also be the case that if a native KDE version of Scribus was to be
> created, it would be better as a standalone app rather than a part of
> KOffice.
>
> Naturally all this discussion is moot if Franz Schmid isn't interested in a
> KDE version of Scribus and no-one else is interested in creating a port.
>
> > Regards
> > Dirk
>
> Cheers,
> Sean

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]