Rony G. Flatscher wrote: >> 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).
If anybody else would want to work on that: I'd support it. But I don't see us (the "regular" developers) working on this in the forseeable future. Not with the resources we have. We would need at least one other very compelling reason to think about reimplemening our "middle tear" code. This could be a change in the GUI toolkit, architectural requirements, 5-10 volunteer developers or the same number of them paid by someone else. Or something else that currently doesn't come to my mind. >> 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)? I don't have a current list of dispatches at my hand. I've found a quite old one (3 years old) on my laptop. It showed me roughly 1500 dispatches, many of them are implemented multiple times. From my experience with this stuff I'm sure that nowadays it will be rather more than less dispatched. So I don't think that an estimation of 2000-3000 dispatches to be implemented (in all apps together) is not completely wrong. > 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! But documenting what to do *is* a complete rewrite, at least in terms of development time investment. Once you have designed a feature sufficiently and described its implementation so that even external developer could code it writing the code by yourself would be a piece of cake. So we have the situation I described: whether you take this new implementation only to generate the scripts or also for the implementation driven by GUI interactions is a trade-off between code size and testing effort / regression risk. But it doesn't make a big differnce wrt. development time. 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]
