Hi Matthias, Mathias Bauer wrote: >> But then, wouldn't this also mean that this Dispatch API is excercised >> by all OOo modules then, including Draw/Impress, or is it the case that >> for using that API some of the module-dependent (C++ implemented) UI >> elements still need to be programmed accordingly? >> > > The Dispatch API is the same in all modules - but this is a generic API > and the "real" action lies in the command names and paramters. All > objects have the same interface to receive commands but they differ in > the commands they support and - in case of Draw/Impress - also in the > degree of how good their implementation actually is. In Draw/Impress > parameters are mostly not supported at all and they are essential for > playing recorded macros. That's enough for calling the Dispatch API from > the GUI (where usually no parameters are sent) but is a killer for > playing macros using the API. > > Besides that: this is only the "playing" side, in Draw/Impress the > recording side even looks worse (remember the rule set for recorder > support I posted earlier). > Given all of your information, I very much tend to believe that. ;-)
>>>> 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. >>>> >>> The reverse mapping that we can do is what the current macro recorder does: >>> all received "dispatch()" calls are recorded. >>> >> Hmm, would it be conceivable then to come up with a static table of >> dispatchable user-actions with a sequence of UNO API invocations that >> would be needed to be excercised such that for recording purposes this >> list could be used in addition, recording the values of arguments and >> results and so on. Or with other words, for every dispatch have an >> independent, alternitve thread of creating UNO pseudo-code necessary to >> arrive at the same functionality, stating pre- (which UNO objects, >> methods, argument values) and post-conditions. Maybe even including >> branch statements, or with other words, small (commented) pseudo-code >> segments that could be used to map to a concrete language later on. >> Either being editable to correct or supply addtional code/information. >> > > You have described "reimplement the glue code" with other words. Yes, of > course you can reimplement each and every dispatch call by using UNO API > calls. You can do this in the glue code itself (thus replacing it) and > record these calls or you can have a parallel implementation somewhere > else as you described or Paolo Mantovani already did for some Calc > dispatches. But it's a reimplementation in all cases! The difference > only is that in your case the original code is not replaced but its > effect on the document is achieved differently. This has an advantage > (no regression risk as the original code is preserved) as well as a > disadvantage (OOo's size will grow considerably). And it's time > consuming in every case. > Yes, but one would have to start out *documenting* what should happen in the UNO world to match a particular dispatch call in any case! Even if you started out without the existing dispatch calls you'd still be forced to document/define what should be done in UNO to map what is sought for in the C++ implementation. Or with other words: you can't get a new macro recording in place without efforts! The question would be how to achieve this as quickly and resource-saving as possible, if you are serious in creating and supplying a full featured macro recording eventually (hopefully within one, two years). >> Even if it is not perfect and may contain omissions or incomplete >> information it may generate UNO based code that needs a little bit of >> "massaging", it would be so much more and a starting point that really >> may drive up productivity. (Obviously looking for a Pareto solution, >> i.e. 20% effort for covering 80% of the needed functionality, leaving >> the missing 20% to the UNO/OOo savvy programmers.) Power end-users would >> be able to create that skeleton then rather easily, needing UNO/OOo >> acquainted programmers to turn it to a running macro. >> > > Now we are at the point where we started: writing down the correct set > of UNO API calls for each dispatch call will first force us to deliver > the missing APIs and types and then will take years to implement the > calls. We have thousands(!) of dispatch calls to implement. Some of them > also depend on internal states. The command ".uno:Delete" e.g. must be > implemented completely different depending on what is selected. > Not sure (again not knowing anything about the inner workings, hence pure speculation) about this conclusion. How many dispatches are generated via the GUI resp. via the current macro recorder, are these *really* "thousands" of different dispatch calls that are *directly* caused by this? Or would it be more in the hundreds (which would make a big difference)? For the core-developers it would be the task to supply machine readable documentation of what the dispatch call does by supplying the matching UNO sequences. It would not (!) be a new (partial) implementation of the glue code at this stage! In order to do that documentation systematically there should be use-cases defined (e.g. "search and replace", "defining a shape", "adding a new formatting rule", "printing a selection", "mail merge", "exporting", "importing", "creating a link", "embedding some object" etc.) for which all of the dispatch calls get documented that way (which would be initially just a very small fraction of the dispatch calls). Then macro programmers who know UNO could come up with matching implementations in their macro language from this documentation (possibly automatically translating from the machine readable, and hopefully intelligently ;) structured docs to the respective language of interest, e.g. OOo Basic, Java, etc.). Just running such macros would then show quite quickly whether the documentation (UNO invocations matching the dispatch calls for a specific use case are complete/error-free, and if not, then even this group of people could jump in to help to fully/error-free document the needed steps in the UNO world to carry out the respective use case successfully). If such an endeavor was backed with a database where you would have the use-cases, the dispatch calls and the matching sequences of UNO based invocations in a neutral, structured, machine readable form, then one might even think about the automatic generation of macros/programs in a desired target language at the press of a button. :) (Besides, over time it would allow for cross-referencing and for many forms of analysis.) Initially it would be a documentation & knowledge base, which may grow over time and cover all of OOo, or at least all building-blocks dispatch calls needed for macro recording. At least we would arrive at use-cases how to achieve certain tasks in OOo with the help of UNO, and even have macro code for that generated! (Of course once the mapping to a certain language could be successfully established, then it might become possible over time, to generate even the new glue code from it.) Again, this is pure speculation and could be totally undoable, but maybe not. Ceterum censeo, new macro recording ... ? ---rony
