Rony G. Flatscher wrote:
> This is what I object to: that macro recording was not really "that"
> important. In the contrary, macro recording is of utmost importance for
> end-users who wish to automate their businsess processes i.e. record
> re-curring actions and re-play them later, without any need of knowing
> how to program! Without end-users no need for other technical
> improvements, without such an important "building-stone" feature MSO
> aficionados can quite easily keep OOo off the door.
Of course nearly every issue is of utmost importance for a particular
user group. At least that's what I read from many issues - a lot of them
contains lovely statements from "this is the one issue that prevents me
from using OOo", "I can't believe that this isn't implemented already",
"An application without this feature is crap" etc. etc.
So here the rule "if everything is important nothing is important"
applies. In result the project members must decide by themselves.
Without any data backing up that 2 man years development time for
improved automation support (plus QA etc.) will please more users than
those who can become pleased by what we can do instead of this
(improving usability, filters, performance etc.) I don't see it happen.
> Of course there are many, interesting, worthwhile RFEs out there, which
> should (all) be implemented. However, that fact should not lead to the
> wrong conclusion that "macro recording" was not "that" important at all.
Sorry, that wasn't the impression I wanted to create. This is true only
in the meaning I wrote: if everything is important ... If we saw it as
totally unimportant we wouldn't have tried it at all.
> Both are independent, important development routes. Macro recording in
> this context is of strategic importance. In the past OOo/SO developers
> have appreciated that and implemented it (even if it was done in a way
> that today does not appear to be appropriate).
IMHO the Dispatch API approach is a good one in case we wanted to target
only the automaters and in fact this was our intention. Perhaps we
should have created binary macros only, without showing any source code.
In fact that was my proposal but that wasn't well received at that time.
That would have explained much better that we never wanted to provide
that "real" macro recorder that we think we can't deliver in a
reasonable amount of time.
> (Speculation, of course!) It looks to me that at one point in time it
> was "common knowledge" among the developers that the macro recording
> should be done to allow replaying it via the dispatch interface was not
> optimal and should be eventually replaced.
Not really, as I wrote, the original intention indeed was to create an
automation tool, not a "developing macros teacher".
> Then Draw/Impress got
> developed further and macro recording was left out, because the existing
> technology was not optimal, but no alternative has been established.
Draw/Impress never had any useful support for this so from the beginning
we had to implement it from scratch - even the Dispatch API based
recorder. Even in Writer and Calc, where some basic support was still
available, it took us some months to come to where we are.
> Hmm, please take the following just as an attempt (maybe a poor attempt)
> to think the impossible:
(snip)
I'm afraid that reading and understanding your thoughts will require
some time. But a first glance showed me that you think about
intercepting calls ("urp"). As this will require UNO calls that could be
bridged I'm not sure if I made myself clear enough. So before I dig into
your ideas deeper (and I will really try to) please answer these question:
Do you agree that my explanation on the wiki page made clear that
whatever we do we can't build upon UNO and UNO APIs as this would
require a complete rewrite of our "glue" code that currently does not
use any UNO runtime or UNO API calls? In a 3-tear-model that would be
the middle or "basic interface level" (BIL) or however you want to call it.
So what we have is the level of pure C++ function calls. IMHO there is
nothing you can record and play, you always need an object model to work
on and that's UNO.
BTW: do you plan to be at the OOoCon in Barcelona? Talking about this
face to face with some code to look on (and hack ;-)) would be much easier.
Ciao,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
