On 3/31/10 3:13 PM, Lars Nooden wrote:
On 03/31/2010 01:12 PM, Martin Hollmichel wrote:
... As start I created
http://wiki.services.openoffice.org/wiki/Smp_status_2010 for collecting
a status of the recommendation done in 2004.
O-W
+ The macro issue can move on to this decade by emphasizing support for
scripting in python and javascript. A great many applications and
systems use one or both. Chasing M$ junk is a waste of time because 1)
the macros will have to be re-written anyway because of the hooks to M$
packages and platforms, 2) any picayune differences, real or perceived,
can be used to dismiss the whole package, 3) by the time it is 1:1
bug-for-bug compatible tons of resources will have been wasted and it
will be beyond old - the way to win the Red Queen's Race is not to
enter, 4) python and javascript work *now* with existing skillsets. If
an additional scripting language is needed, then Lua could be
shortlisted for consideration.
Although it is hard to convince costumers who have a lot of existing
documents with containing macros i personally fully support this.
Our main focus should be on ODF and automation based on our product with
our own API, good documentation and good examples and most important
good tooling that makes it easy for users to create their own small
automation solution.
A good and working macro or better script recorder would be one thing.
Recorded scripts that can be easy extended later manually.
A good and easy to use IDE with all the nice gimmicks that are available
today (e.g. code completion).
Juergen
O
+ Clip art can be a way to reach out to various communities. It would
make sense to try working with other ODF-based suites (e.g. Koffice) and
existing art projects like OpenClipart and maybe even distros.
+ Documentation at OOo Authors should be seen as a marketing advantage
and kept fresh. Many capabilities essential to large enterprises, such
as digital signatures, are not widely known or adequately used. There
are a number of print-on-demand shops that could be used as supplemental
distribution channels and to provide income to the project.
/Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
