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

List:       koffice-devel
Subject:    Re: Mathematics with koffice
From:       Ulrich Kuettler <ulrich.kuettler () mailbox ! tu-dresden ! de>
Date:       2003-03-18 11:55:04
[Download RAW message or body]

On Tuesday 18 March 2003 05:54, Christian Parpart wrote:
> > >
> > > Think about it, it's possible.
> >
> > Uhm. Yes, indeed. You are right. It's indeed possible. It's not as easy
> > as your code suggests, just think about graphical programming or plotting
> > functions, but still it can be done.
>
> *heh* My code I suggested was just in time coded as I was writing
> this mail ;) So, of course, it may provide more.  But the question is,
> do you want an office application or a science framework for maths
> and others(?).

I fully agree. That's the central question. And as we talk about koffice I 
have a strong preference for the former. koffice is aimed at people that want 
to get their stuff done without being scared away by software internals.

That doesn't claim a science framework to be a bad thing. However, there is 
texmacs. (And others...) ;)

> > However I doubt if it's worth the trouble. After all, if it's done right
> > you could switch the backends and wouldn't notice a difference. The idea
> > was to completely hide the backend. So what could be gained by changing
> > it?
>
> The ability to switch alternatively to a different backend that supports
> the feature X more stable (think of recurive functions, infinite numbers,
> etc.) Although to extend the functionality by replacing the old backend
> with either a newer version or even another once, where the second
> point is more important.

It's questionable if this flexibility can be achieved. And this is not a mere 
technical question. You need to communicate to your users how to combine 
which backends with which adapters to get certain sets of features with 
certain bugs. That's not the kind of question an office user wants to think 
about.

> science work. Do you want him to use everything but koffice, just because
> he can't/doesn't want use M?

Nobody who doesn't want to needs to do maths with koffice (even when it's 
possible... someday.) If he is happy with what he's got, why should he bother 
with something new?

>
> > (That's really a question to me. Even if I cannot promise to implement
> > the biggest possible solution very soon I'm very much interested in what
> > is needed.)
>
> For this, I'd suggest that we make a proposal of what we really want
> koffice can do and what of them may stay optional.
> Also, note, putting most features in doesn't really feature koffice for sci
> workers, a to full bloated application doesn't seem to be an invitation for
> every interests.

My current plan is to build the smallest package that could possibly be 
useful. From there it will be possible to add more. So I want to be able to 
(a) evaluate formulas numerically, (b) plot functions, and (c) define 
functions graphically pretty much the way MathCAD does. This surely won't 
make a huge scientific application but will be valuable for many ones that 
need to do some simple computation quickly. Heavy scientific work will need 
other tools.

>
> Shall that (unified) scripting language be for the user-level or for
> koffice itself to bridge the backend or (as I propose) for the backend
> currently used?

I don't see a difference between the user-level or koffice itself. Just think 
about emacs or texmacs. The backend's scripting language (that only the 
advanced koffice user will know about) is a completely different story.

>
> > > However, I definitely vote for a interface bridge to support multiple,
> > > different back-ends of math engines. This would even allow me to use my
> > > own yet not that featured implementation of math engine, libmath++
> > > (which is fully featured by C++, no c no lisp no f/f77).
> >
> > Interesting. Is there any code to be seen yet?
>
> http://freshmeat.net/projects/libmath/

Nice. ;) 
(Who doesn't like Kaesetorte?)


Greetings,
Uli

_______________________________________________
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]