shiny uno version, Desktop IDL

[Michael Meeks]

Hi Stephan & Noel,

On Wed, 2012-06-13 at 15:22 +0200, Stephan Bergmann wrote:
> I wouldn't introduce the extra noise of an additional Desktop2 service. 
>   While technically it would be an incompatibility to change the 
> existing, old-style Desktop service (implementing multiple interfaces) 
> into a new-style one implementing a single new XDesktop2, practically it 
> should have little consequences.  (As old-style service definitions are, 
> after all, little more than "glorious documentation."  I hope I don't 
> miss any obvious blocker here.  Anyway, one would need to try this out 
> to be sure.)

	I was amused to read the Desktop service and see:

    /** @deprecated This interface is a documentation error. It was never thought to be supported
                    by this service. Please use the service <type cope="com::sun::star::frame">GlobalEventBroadcaster</type>
                    instead of this interface.
     */
    interface com::sun::star::document::XEventBroadcaster;

	:-)

	What new methods did we want on XDesktop2 out of interest ?

> But thinking about it, that approach might just be a good one:  We start
> to do changes incrementally now, based on status quo, improve them over time, 
> and by the time of an all-incompatible LO 4 have something new (but 
> already time-tested) and we can remove any stuff that has become 
> obsolete (and potentially clean up the new stuff, like renaming 
> XDesktop2 back to XDesktop or some such).

	So - to get this clear; we would have a 'Desktop' service that is
instantiated all over the show:

m_xMSFactory->createInstance( ::rtl::OUString( "com.sun.star.frame.Desktop"  ) )

	That wraps a load of global state; but of course, we don't really have
a 'Desktop' anymore ;-) so any chance of a more friendly & helpful
variable name ? say "Application"

> The only problem is with publishing:  Ideally, the new XDesktop2 should 
> remain unpublished for now.  However, the existing (published) Desktop 
> service could then not be rewritten to use XDesktop2.  Solutions would 
> be to either:

	Would the XDesktop2 re-implement same methods as XDesktop - if so, I
guess scripting bindings would have some sort of nightmare trying to
disambiguate them.

	If we are creating a monster, easily accessible top-level instance; it
might be rather good to fatten / widen our API to make it easier to use
for scripters. What do I mean by that ?

	We currently rely on a lot of service activation by string to get
global state, which is fragile, and non-completing for many languages /
IDEs but I would -love- to have a lot of this stuff tied into a nice big
top-level 'Application' API.

	So - as an example; I would love a:

	any  getConfigKey([in] string path);
	void setConfigKey([in] string path, [in] any value);

	Cheesy, incomplete - if you want more you have to go to the real source
- but, at the end of the day it would cover 99% of the simple, extension
use-cases I think. IMHO there are a set of objects and features that are
rather unpleasant to use & find that we could make much easier in this
way. Another example might be opening a stream via the ucb - which could
be wrapped with a single, simple 'fopen' style method.

	Similarly focusing on scripting bindings we have:

    com::sun::star::lang::XComponent getCurrentComponent();

	I would prefer that to be:

    [property] com::sun::star::lang::XComponent activeDocument;

	or somesuch - and preferably with a wider / fatter interface than
XComponent :-) Perhaps with a getActiveDocument() method for the long
suffering C++ users who don't want an any in the way.

	Of course any purists lurking here will immediately want to fragment
what I just wrote into a dozen separate, one method interfaces ;-)  but
my thesis is that queryInterface destroys usability - particularly from
scripting languages wrt. autocompletion, and also makes documentation
rather unpleasant.

	ie. put another way - I'd like to re-focus our UNO interfaces from the
bottom up (of which XDesktop is a great starting point) to be -far- more
useful, and usable for scripting - IMHO -the- primary use-case for UNO
and where it can excel. The VBA compatibility interfaces may provide
some useful inspiration here I suspect, and more than that I imagine
that going and reading a small number of StarOffice basic macros (and
the somewhat shameful VBA migration guide ;-), and working out how we
can make scripting more succinct and efficient would be wonderful.

> C  Temporarily remove the codemaker check that prevents a published 
> new-style service from using an unpublished interface.
>
> I could envision going down route C.  What do others think, overall?

	Sounds sensible to me; we might want a hard-to-tweak black-list of such
interfaces hard-coded in some horrible way (in the tool? :-) to
discourage too much of this ? ;-)

	Is that too radical ? :-) good bike-shedding fodder anyhow.

	Thanks for bringing it to the list,

	Regards,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot