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

List:       koffice-devel
Subject:    Re: Linux Format: KSpread "disaster area"
From:       Robert Knight <robertknight () gmail ! com>
Date:       2006-01-14 14:10:54
Message-ID: 13ed09c00601140610j678988beu () mail ! gmail ! com
[Download RAW message or body]

> what can be translated to a wish for us to be dependent on WINAPI (wine?) and
> to add a few millions of lines of dirty code for VBA API support.

I agree, I really don't think there is much point in trying to achieve
perfect compatibility with Excel.  The OO.org hackers have put a lot
of effort into this, more than we probably could.  A better (more
stable) Excel import / export filter that can handle most of the
features KSpread supports would definitely be welcome though.

Having said that, I think that when we market KSpread, we should be
clear than OpenOffice is a better alternative for people who need to
work with complex Excel spreadsheets.

When it comes to macros, there are definitely advantages to having
them, but VBA support would be overkill.

On 13/01/06, Jaroslaw Staniek <js@iidea.pl> wrote:
> Robert Knight said the following, On 2006-01-13 20:29:
>
> > I'm not so sure about that, for two reasons:
> >
> > - Macros are incredibly powerful tools, and there are many situations
> > where ordinary spreadsheet functionality doesn't cut it.
> >
> > - Although writing macros might be "hard", using a spreadsheet with
> > embedded macros (written by someone else) is not.  To give a personal
> > example, when students needed to order components for electronics
> > projects at my old school, they would use a template spreadsheet
> > containing some simple macros produced by the teacher.
> > Less technical users or those simply wishing to save time can also
> > download sample spreadsheets with built-in macros from the web.
> >
> > Perhaps adding such functionality would be a good opportunity for
> > KSpread to score one over the competition.  By that, I mean making
> > macros easier to author in KSpread than other software, or a better
> > security model, or something else I haven't thought of.
>
> from the typical-flame-against-biased-or-uneducated-reviewers dept:
>
> I didn't RTFA (yet?) but I _hope_ the reviewer didn't think
>
>           "KSpread doesn't RUN MS VBA macros!",
>
> what can be translated to a wish for us to be dependent on WINAPI (wine?) and
> to add a few millions of lines of dirty code for VBA API support.
> At least many ordinary human beings I listened (e.g. regarding OO.org)
> considered such support (read: utopia) as a good thing. Do I hear LOL?
>
> Indeed chances are that applications utilizing KROSS layer will get relevant
> advantages in terms of security/flexibility. Quite possible with _sane
> portable defaults_ and strategy better than "let's add this feature/language
> because it's cool to have it too".
>
> (my 0.02 PLN)
>
> --
> regards / pozdrawiam,
>   Jaroslaw Staniek / OpenOffice Polska
>
>   Kexi Developer:      http://www.kexi-project.org | http://koffice.org/kexi
>   Kexi Support:        http://www.kexi-project.org/support.html
>   Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
>   KDE3, KDE4 Libraries For Developing MS Windows Applications:
>                        http://www.kdelibs.com/wiki
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
_______________________________________________
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]