Hi Matthias,
> So here the rule "if everything is important nothing is important" applies.
Right!
> 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.
>
That is really the point: how to assess what is (really) important for
what purpose. Current users of OOo have a high interest in the latter,
i.e., constantly improving the current OOo, filling "felt" gaps here and
there; like Base now getting a great reporting facility (which is very
important, needless to say). Of course macro recording would improve the
usability for current OOo users as well, helping them automate their
tasks ("business process steps"). However, my main-focus would be about
"unlocking" MSO power end-users, who use macro recording (and then have
someone else alter the generated code to suite more their particular
needs, or quite a few times being able to edit the recorded code
themselves in little corners and edges), which would be an ongoing and
strategic goal.
>> 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.
>
Yes, I thought so (really!), but at the moment it seems to be the case
that it is put on the back-burner, short of viable trails to achieve
full macro recording with the scarce resources at hand.
>> 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.
>
Either one would be great, a binary solution, if well-thought out
upfront would allow to write later programs that should be able to
create source code from the binary representation in any of the
languages that support interaction with OOo (i.e. while crafting the
binary specs, also information should be recorded for the purpose to
allow transcriptions later).
>> (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".
>
Yes, the automation tool would be paramount. However, thinking about
allowing the recorded macro to be transcribed to a macro language later
should not be ruled out, as it would allow for many applications of it
(as can be seen with power end-users in the MSO world). This
transcribing would probably be possible to members of the community,
whereas the macro recording funcitonality itself is something which
probably only the core developers would be able to master efficiently
and completely.
> (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.
>
Yes. (But again, I am not aware of the "inner" workings and architecture
put in place, and have no knowledge about what would be still
conceivable and what would not be conceivable at all.)
> 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.
>
But there must be a mapping available which maps from UNO to C++ as
otherwise the C++ code would not be invocable via UNO? A reverse mapping
should be establishable then as well in this case, even if that is a 1:N
mapping (i.e. a C++ function/method gets invoked from different UNO
types), it would at least allow for narrowing down the UNO types, and it
could be possible that from the context one could even narrow them down
further.
But again, this could be total rubbish and not worthwhile to pursue...
> BTW: do you plan to be at the OOoCon in Barcelona?
Unfortunately, no (I do not get funding, if I just attended, i.e. not
doing a presentation of some sort). Maybe next year.
> Talking about this face to face with some code to look on (and hack ;-))
> would be much easier.
>
Yes, that would be a good idea. However, I would need some time to
refresh and brush-up my C++ knowledge beforehand (I used to teach it,
but that is now many years ago, such that my C++ skills have become
quite rusty unfortunately; enough is remaining to read existing code and
knowing how to edit and compile it if there is a "compelling" need; but
the knowledge about many of the C++ idosyncrasies has faded).
---
Ceterum censeo, macro recording ...
:)
Regards,
---rony
