Hi Matthias, > Of course Draw/Impress has a "macro facility" but not a "macro recorder" > and nobody wants to remove this facility. > I see that this is what you meant - but please let's be accurate, > rumours spread faster than you can imagine and next week you can read > somewhere that we are going to dump Basic macros in Draw. ;-) > Yes, you are right! Of course Draw/Impress does have a "macro facility", but not a "macro recorder"!
>From here on everything is a totally personal opinion and may be erroneous due to lack of understanding/knowledge of some or all of the underlying technologies/infrastructures. <begin opinion, feelings, not quotable as facts> >> Just my 2 cents. >> > I'm afraid that 2 cents won't be enough, but in case you could invest 20 > million cents we could think about implementing the dispatch macro > recorder in Draw/Impress and fixing the existing one in Calc and Writer. > I doubt that it would be possible with less effort. There are still much > more areas in OOo where this investment is placed a lot better. This is > 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. > what "too much effort for the expected benefit" means. In the same time > you can implement much more things that much more people need. > 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. 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). (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. 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. At the end (today) it looks as if the snake has bitten its own tail, and macro recording is in agony (downgraded to unimportant/not worthwhile in the mindset of some/all developers). > But this simple recorder still isn't the "real" recorder that developers > and development newbies want, they want a tool that teaches them the > "real" OOo API (not the Dispatch API), not a simple automation tool. > > I have written a wiki page > > http://wiki.services.openoffice.org/wiki/MacroRecorder > > that describes the situation. Please everybody interested in this read > it, and read it completely before you reply. If something is unclear of > if you think that something is wrong please let me know it. > Thank you *very* (seriously!) much for your efforts and explanations there! > I hope that this will make clear where the problems are and why it would > be such a huge effort to provide a "real" API macro recorder. > Hmm, please take the following just as an attempt (maybe a poor attempt) to think the impossible: * Tabula rasa: assume no macro recording were present at all, how to add that functionality as quickly and "effortlessly" as possible? o As we have macro recording in some modules and not in others, why not attempt to start out in thinking from nowhere (pretending it did not exist yet). o The following two ideas are just ideas, because I do not really know the internals of UNO/OOo, I just have an outsider's view, which many times is a bird-eyes view (drawing concepts and assumptions from earlier SOM/DSOM/CORBA). The general idea is that some means is added that would indicate that some new recording mode is active or inactive, a call level and an object to use to record the invocation and returned value), and if set to active recording it should take place. + idea "urp": in the case that each UNO/OOo related request/invocation of a method/function needs to be dispatched via urp, possibly applying marshalling, then why not create the recording code there: it would be possible to learn which object's method with which arguments has to be dispatched, and also what return value, if any, would be returned # Of course, from your Wiki page it may be concluded that for C++ urp is not necessarily excercised; if so, would it be possible to define a mode in which even C++ would use urp (maybe only temporarily for the duration of the recording session)? + idea "aspect programming": it has been *quite* some time that I really worked with C++, and because of that I am not acquainted about the state of the art of aspect programming for C++. The idea would be as follows: inject recording code (maybe if not at runtime than with scripts right on the C++ source code) at the top of a function/method recording the object, name, arguments, and inject recording code everywhere where return values exist in that function/method. * What should be recorded and how should it be encoded? o The starting point (i.e., whatever macros already get supplied with if invoked for an OOo document) information. o Assuming that the user interactively starts recording a macro all invocations of functions/methods thereon caused by the user should be recorded. Whatever function/method invocations occur because of that in the background is not interesting. [Even if a mouse-moving action of a user gets recorded with possibly hundreds of function/method invocations, these should be recorded (it would be eventually possible with heuristics to cut that amount down).] Hence assuming that user interactions occur at level 0, each invocation of a method/function would bump up the level by 1 (done by the recording code), only level 1 invocations would cause the invocation to be recorded. o The object, the method, the arguments and the return value should be recorded. If an object gets used later as an argument or as the target of invoking a function/method it should be possible to learn that that object is already known in the recording session and merely re-used. o The representation of the recorded invocations should be as language neutral as possible (encoded as byte-code, as XML-text, etc.), such that it would be possible for any language to learn everything needed to create a program of it that would replay the invocations that the user caused. In any case recording of type information (as fully qualified IDL names) and UUID of the objects in the recording session (in order to find out which objects are the same, i.e., are reused in the course of the macro recording) would be needed. Again these are just coarse ideas (ideas/thinking would be needed for dealing with dialogs and the interaction of users there, which seems to be one of the challenges; but depending on the dialog architecture one might be able to figure out the fields and values at popup-time and the fields and values at popdown-time, resp. whether a dialog was closed with an undo action, i.e. the invoking of the dialog could be dismissed totally from the recording). Not knowing the inner working of UNO, I have no idea what problems may be hit (and would have to be solved). But at least at this coarse and unspecified level it may help to find other means/ideas/concepts to define a new macro recording framework that is feasibly implementable as quickly as possible. Would in theory any of these ideas allow a workable solution in your opinion? Not having all OOo modules equipped with macro recording would pose a constant (strategic) problem. (What I see about "power" end-users doing with MSO macro recording is very impressive and locks them into MSO.) </begin|end opinion, feelings, not quotable as facts> ---rony
