Rony G. Flatscher wrote: > > Mathias Bauer wrote: >> Rony G. Flatscher wrote: >> >>> But there must be a mapping available which maps from UNO to C++ as >>> otherwise the C++ code would not be invocable via UNO? >>> >> Of course: this is the Dispatch API! The UI elements use die Dispatch >> API to call a method in a UNO object implementing >> com.sun.star.frame.XDispatch. This is the only UNO based call involved. >> The implementation of this object only uses pure C++ calls inside, >> nothing based on UNO APIs, neither in-process nor remote (urp). >> > 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). >>> 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. > 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. 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]
