Re: shiny uno version, Desktop IDL

On 06/14/2012 12:50 PM, Stephan Bergmann wrote:
> 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.")
>
> > > 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.).

Noel,

After all the flamefests in this thread  ;)  ---are you still interested 
in exploring down the route outlined above?

I would be interested in getting experimentation done in that direction, 
to learn how best to move towards an incompatible LO 4.

Stephan