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

List:       koffice-devel
Subject:    Re: Article: Macros an obstacle to office suite compatibility
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2005-09-17 20:56:30
Message-ID: 432C82FE.4070506 () iidea ! pl
[Download RAW message or body]

M. Fioretti said the following, On 2005-09-17 19:03:

> As per subject:
> 
> http://software.newsforge.com/article.pl?sid=05/09/09/1640253

Marco, thanks for these points. This is another time after "The Lack of a 
Small Unified Database" you've inspired me for discussion :)

So, BTW, Koffice developers, let me keep you informed:

1. from the article: "Some KOffice developers, for example, have thought about 
integrating a Python interpreter."

Among others, that's also Kexi "preference". We're in progress to deliver 
support for Python scripting;
see http://www.kexi-project.org/wiki/wikiview/index.php?Scripting for more.

2. from the article: "On the other hand, OOo 2.0 should support another easy 
way to implement simple logic (that is, our "document" macros) without any 
programming"

Again, this is also an "in progress" module within Kexi (note that "macro" 
term is used like in MS Access, not as "script"):

http://www.kexi-project.org/wiki/wikiview/index.php?Macros

3. the W3C XForms standard, which is not tied to any specific program. Why not 
go straight for XForms, and forget traditional macros altogether?

We're all with this idea! _EVEN_ if applications, like Kexi, are not 
internally built around this format, it can be easier _adopted_ to be used, 
even by default, if OASIS picked XForms as a "recommendation" or so; you know 
what I mean. It's possible to agree here. Doing the same with _ANY_ of 
scripting non-trivial language is not possible in practice.

Because Kexi project has found tallented developer (Sebastian Sauer, devoted 
to developing a scripting engine, KROSS), both scripting and macros are being 
developed, we can say, in parallel. However, if you are planning to have some 
sort of automation incorporated into your KOffice (or even outside), 
application, my proposal for you is to first look at supporting _macros_(*) 
rather, because it's not only _easier_ game, but also because it's _safer_, 
what the article reminds us. If you're ok with this, we can share ideas and code.

RFC.

(*)Note: this doesn't have to be built on top of DCOP interfaces within your 
app, but if you have these defined, part of the work is already done.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska / Kexi Team
  http://www.openoffice.com.pl  |  http://www.kexi-project.org
  KDElibs/Windows: http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32
_______________________________________________
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]