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

List:       koffice-devel
Subject:    Re: KOScript, again (long)
From:       <weis () stud ! uni-frankfurt ! de>
Date:       2001-08-31 16:53:22
[Download RAW message or body]

Hi,

On Fri, 24 Aug 2001, Werner Trobin wrote:

> Hi!
> 
> As you all probably know, KOScript has been "invented" to have
> a secure version of KScript for usage in KSpread. The current
> state of it is "suboptimal", tho, as we can't input Unicode and
> stuff like that. It also has various locale problems and if you
> really want to use it as "scripting language" it offers an
> extremely odd syntax.

When I split KOScript from KScript my intention was mainly
to provide a way of extending kspreads math capabilities.

KOScrpt was not intended to do real scriptingt with dialogs and stuff.

> Therefore I wanted to "have a look" and try to fix some smaller
> issues in my holidays. After having that "look" I found out that
> more work is needed :}
> 
> Basically KOScript is still too powerful to be used as plain
> KSpread formula language (what it definitely is right now ;).
> I also don't see any other application in need of such a thing
> (as we have DCOP for scripting anyway), so I think it would be
> the best if we strip that even more and move it to KSpread.
> We might also want to (re)move kscript (e.g. to our "corba"
> module >:p)...

KScript is dead. And you are right. The purpose of KOScript is
to do math.
 
> My idea was to strip down KOScript to a plain formula language
> and to have all those nice DCOP interfaces for "more powerful"
> scripting (i.e. for stuff you would use VBA in MS Excel). The
> DCOP part is already there and it's easy to extend that as soon
> as some more functionality is needed (it's quite complete, tho).
> This also was the result of the security/scripts discussion, AFAIK
> (no scripts in documents).
> 
> There are several questions of course, and I'd really like to get
> your input on that:
> 1) How to make KSpread files easy to transfer to different countries?
>    Well, the easiest way is to store everything in "C" locale settings
>    and do the conversions on loading/saving obeying the current locale
>    settings. It should be possible to do that in a way that we don't
>    lose information. These locale specific things include settings
>    like decimal points, thousands separators,...

See my previous mail.
 
> 2) What do prefer during runtime? Should KSpread handle locale specific
>    things and store "C" versions internally, or should KSpread work
>    with the current locale settings and let KOScript mess with that?
>    IMHO KSpread should work with the user's locale during execution as
>    it seems to be easier to handle (and is probably faster for repainting
>    and related things).

It should use the locale of the document.

>    I played a bit with KOScript today and it seems to be possible to solve
>    that problem in the scanner. Related to that problem of decimal
>    separators is the question of function parameter separators. AFAIK MS
>    Excel handles that by using a plain comma (',') in the US version and a
>    semicolon in the German version (';') as the comma is used as "decimal
>    point" in Germany.

Yes. See my previous mail.
 
> 3) Unicode strings in formulas?
>    As I already told you, flex is not able to handle multi-byte characters,
>    but I think it should be possible to transfer string literals as UTF-8
>    strings. This would look like "full" unicode support as all our keyworks
>    are ASCII anyway ;)
>    This raises a question, tho: Does a Russian, Korean,... user type
>    =SUM(...) or not? Do they have the possibility to input ASCII text?
> 
> 4) Language dependent keywords?
>    This question is strongly related to the previous one. Do we want to have
>    support for "localized" keywords (like in MS Excel)? For example, do we
>    want to have "SUMME" as German translation for "SUM"?
>    The first idea would be to implement that in the scanner, but  this is not
>    and option due to lacking Unicode support. The remaining option is to have
>    a "filter" between KSpread and the scanner, but this sounds slow ;)

Personally I always hated the SUM/SUMME stuff, but from a simple users
point of view it might make sense. However, technically I dont have
a good idea right now.
 
> 5) Do we want to allow upper/lower/mixed-case input? As soon as KOScript is
>    stripped down to a "formula interpreter" there's not much point about
>    case sensitive operation anymore. It would be even easier for MS Excel
>    users as Excel also allows that IIRC.

KOScript should ignore the upper/lower case.

Torben

> 
> Comments? Flames? Suggestions?
> 
> Ciao,
> Werner
> 

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