Re: shiny uno version, Desktop IDL

On 06/14/2012 11:22 AM, Michael Meeks wrote:
> 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;

Good point.  So one should leave that out of XDesktop2.  (When changing 
Desktop service from old to new style, one should probably keep 
information about the old structure as documentation, like 
"Historically, the old-style Desktop service supported the old-style 
Frame service and the XDesktop, XComponentLoader, and XEventBroadcaster 
interfaces, where support for XEventBroadcaster had been a documentation 
error that has been corrected now.")

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

No idea if we want any new methods there.  (For context, see Noel's "How 
about if I introduce a new interface XDesktop2 that implements the
necessary interfaces [to allow Desktop to become a new-style service, 
which can only implement a single interface].")

> > 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"

What do you mean with "variable name"?  "Service name," rather?

Seeing that Desktop is implemented as a one-instance service (meaning 
that all calls to createInstance return the same instance; see 
DEFINE_XSERVICEINFO_ONEINSTANCESERVICE in 
framework/source/services/desktop.cxx), it should rather be replaced 
with a (new-style) singleton, anyway.

That way, at least for this specific case of the Desktop service, we 
nicely avoid any published-vs.-unpublished problems, anyway:  Leave the 
old Desktop service untouched (just mark it as deprecated in favor of 
the new), and create a new singleton theDesktop (or even theApplication, 
I have no big opinion on what is a good name there) that implements the 
new XDesktop2 (or whatever is deemed the best name there).

> > 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.

This should work fine, as scripting would see the given object implement 
XDesktop2 rather than XDesktop, so would call the appropriate 
XDesktop2-based methods.

But ach, stupid me.  (I *knew* I missed something when I wrote "I hope I 
don't miss any obvious blocker here.")  The implementation of the 
service would need to support both the individual interface of the 
old-style service (XDesktop, XComponentLoader, etc.) as well as the 
single new XDesktop2 interface.  Thinking about it now, it looks to me 
like that should still be possible, but I might very well still be 
missing the obvious blocker...  (We did think about stuff like this 
extensively back in the day, but one keeps forgetting.) -- Anyway, for 
the new theDesktop-singleton-scenario, a potential way out of any 
problems (if they do exist) would be to base it on a new implementation 
(that can internally forward to the old implementation, even though 
forwarding can be problematic due to "source" parameters of listeners etc.).

[...]
>         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.

queryInterface is largely un-needed with new-style UNO (and not needed 
from scripting languages, anyway).

The fragmentation of the one fat interface effectively is the collection 
of the (new-style) services and singletons.  So, for easier 
discoverability (autocompletion etc.) one would need to make accessible 
that set of services and singletons to the relevant tools.  Short of 
writing, say, IDE plugins that make discoverable the dynamic set of 
services/singletons available in some given UNO environment, one could 
envision a special "fat master entity" for such (scripting) 
environments, that consists of accessors for all the statically known 
services/singletons of udkapi+offapi, say.

So, I think improving practical usability of UNO is possible without 
introducing arbitrary fat helper objects.  All it takes is to finally 
and consistently realize those new-style UNO concepts...

Stephan