Re: Launching a web browser using the PYUNO bindings

Hi,

Thanks Michael for the reply. I'll comment below.

On 16/04/13 13:45, Michael Stahl wrote:
> that rather sounds like a bug if the same thing works from Java.
>
> probably best to debug from C++ the implementation of queryDispatch, if
> the parameters look as expected from the C++ side.

I didn't try with gdb, but I've set some printf calls to trace the
classes involved in the process and why the result is always None.

Notice that the URL has only the Complete field not empty, which affects
the decision of which dispatcher to use:

(com.sun.star.util.URL){ Complete = (string)".uno:OpenHyperlink", Main =
(string)"", Protocol = (string)"", User = (string)"", Password =
(string)"", Server = (string)"", Port = (short)0x0, Path = (string)"",
Name = (string)"", Arguments = (string)"", Mark = (string)"" }

These are the logs I've got in the process:

DEBUG !!! Frame::queryDispatch --
DEBUG !!! InterceptionHelper::queryDispatch --
DEBUG !!! DispatchProvider::queryDispatch --
DEBUG !!! DispatchProvider::implts_queryFrameDispatch --
targetFrameName: _top
DEBUG !!! DispatchProvider::implts_queryFrameDispatch -- TARGET TOP
DEBUG !!! DispatchProvider::queryDispatch --
DEBUG !!! DispatchProvider::implts_queryFrameDispatch --
targetFrameName: _self
DEBUG !!! DispatchProvider::implts_queryFrameDispatch --  TARGET SELF
DEBUG !!! DispatchProvider::implts_queryFrameDispatch --  aURL.Complete:
.uno:OpenHyperlink
DEBUG !!! DispatchProvider::implts_queryFrameDispatch --  Delegating on
controller
DEBUG !!! SfxBaseController::queryDispatch --
DEBUG !!! SfxBaseController::queryDispatch -- target _self
DEBUG !!! SfxBaseController::queryDispatch -- xModel.is(): 1
DEBUG !!! SfxBaseController::queryDispatch -- aURL.Mark.isEmpty(): 1
DEBUG !!! SfxBaseController::queryDispatch -- INVALID model
DEBUG !!! DispatchProvider::implts_queryFrameDispatch --  Searching
protocol
DEBUG !!! DispatchProvider::implts_searchProtocolHandler --
DEBUG !!! DispatchProvider::implts_searchProtocolHandler -- FOUND in the
Protocol Handler cache.
DEBUG !!! DispatchProvider::implts_searchProtocolHandler -- aHandler:
com.sun.star.comp.sfx2.AppDispatchProvider
DEBUG !!! SfxAppDispatchProvider::queryDispatch --
DEBUG !!! SfxAppDispatchProvider::queryDispatch -- NO slot
DEBUG !!! DispatchProvider::implts_isLoadableContent -- Checking whether
is loadable content ...
DEBUG !!! LoadEnv::classifyContent -- Classifying content ...
DEBUG !!! getDispatcher -- xDispatch :  None


> but i'm not sure how this dispatch stuff works, i guess most likely
> you're calling one of these:
>
> sfx2/source/view/sfxbasecontroller.cxx:Reference< frame::XDispatch >
> SAL_CALL SfxBaseController::queryDispatch
> framework/source/services/desktop.cxx:css::uno::Reference<
> css::frame::XDispatch > SAL_CALL Desktop::queryDispatch
> framework/source/dispatch/dispatchprovider.cxx:css::uno::Reference<
> css::frame::
> XDispatch > SAL_CALL DispatchProvider::queryDispatch

From my analysis of the DispatchProvider source code and the
documentation of the Application Environment, I've got some idea what is
going on in the process.

The Web Wizard Frame implements the XDispatchProvider interface, so it
uses the queryDispatch function to get the suitable Dispatcher based on
the URL. This would be perhaps my main doubt, as the URL contains only
the string ".uno:OpenHyperlink", I guess, suggesting the document passed
in the arguments of the dispatcher's "dispatch" method, should be opened
in a browser. That's the way the Java wizard implements such logic, and
I've seen similar code inside Libreoffice, for instance, in the
genericpropertyhandler.cxx file.

What I don't understand well is how such URL is managed in the classes
related to the DispatchProviders::queryDispatch function. Looking at the
logs and the source code, it's clear that the first steps are to get the
_self frame, since _top was initially passed.

As the URL does not match with the .uno:CloseXX commands, it tries to
delegate in the frame controller. Im not sure why, and it would be good
to have it clear, but the SfxBaseController is the one given by the
frame. Since the URL has got an empty Protocol field and the target is
not "_beamer", it tries to use the xModel to get the internal URL of the
component. This dispatcher looks like the one used to dispatch internal
objects of Libreoffice, so it doesn't seems the suitable choice for
opening an external HTML file.

Once the controller is discarded as dispatcher, the DispatchProvider
tries to get it from the Protocol used. It searches in a protocol cache
and found the com.sun.star.comp.sfx2.AppDispatchProvider as the protocol
handler to use. Again, since the Protocol field is empty the first
checks failed, hence the SfxSlot is not retrieved so no dispatcher is
instantiated.

Finally, the DispatchProvider tries to determine whether the URL points
to a Loadable content. It uses the LoadEnv::classifyContent function to
determine the type of the URL. This time, it checks out the protocol
based on the URL.Complete string, instead of the Protocol field value,
which was empty. As the URL starts with ".uno:", it's defined as Not
Loadable.

And that's why I'm getting always Null/None as result fo the
DispatchProvider::queryDispatch call. I think the main doubt is how and
who deals with the .uno:OpenHyperlink kind of URLs, and whether an
additional field is required, beside Completed and even though it was
parsed using the XURLTransformer::parseStrict interface.

I think that's all regarding my doubts; what I'm planning to do is to
implement two tests, java vs python to try to reproduce the issue, and
perhaps figuring out whether there is a bug or not in pyuno. I still
have to figure out how to implement such examples in python and java,
using the LO internal services, but I think there are some examples in
the tutorials.