shiny uno version, Desktop IDL

[Stephan Bergmann]

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