Re: Status of LO embedding inside other processes windows?

2018-02-23 Thread Robert Marcano

On 02/22/2018 07:24 PM, Thorsten Behrens wrote:

Stephan Bergmann wrote:

Most likely, yes.  That LO-in-Java-window thing is brittle at best.


Mmmh - so we have that working in production for a few clients, though
for Windows.


Yes, the example works perfectly on Windows. I have to support both 
platforms, so will initially do some coding with Windows using in place 
LibreOffice and on Linux will use LO on another top level window. LOKit 
will be a long term experiment for us.




LOKit is fine, just it should be noted that ~all UI [1] and
interaction then needs to be implemented client-side.

[1] yes, there's dialog tunnelling, still that needs code to render &
 interact on the client side.

Cheers,

-- Thorsten



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Status of LO embedding inside other processes windows?

2018-02-22 Thread Thorsten Behrens
Stephan Bergmann wrote:
> Most likely, yes.  That LO-in-Java-window thing is brittle at best.
>
Mmmh - so we have that working in production for a few clients, though
for Windows.

LOKit is fine, just it should be noted that ~all UI [1] and
interaction then needs to be implemented client-side.

[1] yes, there's dialog tunnelling, still that needs code to render &
interact on the client side.

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Status of LO embedding inside other processes windows?

2018-02-22 Thread Stephan Bergmann

On 22.02.2018 14:14, Robert Marcano wrote:

On 02/22/2018 07:10 AM, Michael Stahl wrote:

On 21.02.2018 16:55, Robert Marcano wrote:

3- Now both processes should be using GTK2, but the problems with
keyboard input is a blocker


that sounds like a bug somewhere.  (unlikely to get fixed any time soon
given this is quite an esoteric use-case.)


LibreOffice online and if IIRC the Android viewer are more invested on 
using LibreOfficeKit, I think I should investigate that. My knowledge of 
what can be done with LibreOfficeKit tell me I can have an headless 
process rendering to a shared buffer and use that to draw on my Java 
process.


Is this a better long term strategy?


Most likely, yes.  That LO-in-Java-window thing is brittle at best.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Status of LO embedding inside other processes windows?

2018-02-22 Thread Robert Marcano

Thanks for replying.

On 02/22/2018 07:10 AM, Michael Stahl wrote:

On 21.02.2018 16:55, Robert Marcano wrote:

Greetings. I have been playing with the developers guide example [1] for
embedding LO inside a Java window (Swing toolkit). The example works on
a Windows host, but on Linux I found the following problems (in the
order I found)

1- When the host Java application is running on a Wayland session (Java
Swing is still an X11 program), there is a crash. IIRC LO still is a X11
based application (or at least the Fedora compiled version is using the
X11 GTK back-end)

2- Switched to an X11 desktop session, there was no crash this time, but
the document was not shown embedded on the Java window, it was a
floating window with no window controls, unresponsive to the user.

3- Run the same application with the environment variable
SAL_USE_VCLPLUGIN=gtk in order to force the LO GTK2 back-end. The
document is embedded on the Java window as expected, but keyboard input
is not possible on the document or the controls, mouse actions works,
for example, I can change fonts using the mouse, but can't write
anything on the font combobox nor the document. New LO dialogs opened
from that document, keyboard input works.

4- Trying with SAL_USE_VCLPLUGIN=gen and keyboard input now works, but
with the outdated look of that LO VCL backend :(

So now the possible reasons that came to my head for each case:

1- Some confusion between Java being X11 and LO trying to do some
Wayland thing?


by default the "gtk3" vclplug will use Wayland if available.  probably
this won't work if the Java connects to X11 instead.  there is some
environment var GDK_BACKEND=x11 that can be used to force it.


GDK_BACKEND=x11 helps with not crashing on the Wayland session.




2- Java has a GTK Look and Feel/theme that loads GTK2 (the example
application does not load that theme) , I am under the impression that
if LO is loading GTK3, they are on different processes, so should not be
any conflict here.


AFAIK GTK 2 and GTK 3 cannot coexist in the same process, due to some
naming conflict of GObjects or so...


What I find weird is that there is no GTK libraries loaded on the 
process space of the Java example (verified checking /proc//maps), 
even when running the example in-place (not on an independent top level 
window)





3- Now both processes should be using GTK2, but the problems with
keyboard input is a blocker


that sounds like a bug somewhere.  (unlikely to get fixed any time soon
given this is quite an esoteric use-case.)


LibreOffice online and if IIRC the Android viewer are more invested on 
using LibreOfficeKit, I think I should investigate that. My knowledge of 
what can be done with LibreOfficeKit tell me I can have an headless 
process rendering to a shared buffer and use that to draw on my Java 
process.


Is this a better long term strategy?




4- Everything running without conflicting libraries/protocols (Wayland
vs X11 or GTK3 vs GTK2) and work, but the look and feel!!

Now, when running the example with a no inline option, everything works
fine, even when GTK2 and GTK3 are mixed. Wish to have an option to
create the new document top level window as a child of the Java window,
it is a pain for user that the document can go to the back of the
"caller" window. Any hints if this is possible between two processes
like Java and LO?


so does that option run LO as a separate process? yes, that would avoid
some of these issues, but as you found you get different issues instead :-/



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Status of LO embedding inside other processes windows?

2018-02-22 Thread Michael Stahl
On 21.02.2018 16:55, Robert Marcano wrote:
> Greetings. I have been playing with the developers guide example [1] for 
> embedding LO inside a Java window (Swing toolkit). The example works on 
> a Windows host, but on Linux I found the following problems (in the 
> order I found)
> 
> 1- When the host Java application is running on a Wayland session (Java 
> Swing is still an X11 program), there is a crash. IIRC LO still is a X11 
> based application (or at least the Fedora compiled version is using the 
> X11 GTK back-end)
> 
> 2- Switched to an X11 desktop session, there was no crash this time, but 
> the document was not shown embedded on the Java window, it was a 
> floating window with no window controls, unresponsive to the user.
> 
> 3- Run the same application with the environment variable 
> SAL_USE_VCLPLUGIN=gtk in order to force the LO GTK2 back-end. The 
> document is embedded on the Java window as expected, but keyboard input 
> is not possible on the document or the controls, mouse actions works, 
> for example, I can change fonts using the mouse, but can't write 
> anything on the font combobox nor the document. New LO dialogs opened 
> from that document, keyboard input works.
> 
> 4- Trying with SAL_USE_VCLPLUGIN=gen and keyboard input now works, but 
> with the outdated look of that LO VCL backend :(
> 
> So now the possible reasons that came to my head for each case:
> 
> 1- Some confusion between Java being X11 and LO trying to do some 
> Wayland thing?

by default the "gtk3" vclplug will use Wayland if available.  probably
this won't work if the Java connects to X11 instead.  there is some
environment var GDK_BACKEND=x11 that can be used to force it.

> 2- Java has a GTK Look and Feel/theme that loads GTK2 (the example 
> application does not load that theme) , I am under the impression that 
> if LO is loading GTK3, they are on different processes, so should not be 
> any conflict here.

AFAIK GTK 2 and GTK 3 cannot coexist in the same process, due to some
naming conflict of GObjects or so...

> 3- Now both processes should be using GTK2, but the problems with 
> keyboard input is a blocker

that sounds like a bug somewhere.  (unlikely to get fixed any time soon
given this is quite an esoteric use-case.)

> 4- Everything running without conflicting libraries/protocols (Wayland 
> vs X11 or GTK3 vs GTK2) and work, but the look and feel!!
> 
> Now, when running the example with a no inline option, everything works 
> fine, even when GTK2 and GTK3 are mixed. Wish to have an option to 
> create the new document top level window as a child of the Java window, 
> it is a pain for user that the document can go to the back of the 
> "caller" window. Any hints if this is possible between two processes 
> like Java and LO?

so does that option run LO as a separate process? yes, that would avoid
some of these issues, but as you found you get different issues instead :-/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Status of LO embedding inside other processes windows?

2018-02-21 Thread Robert Marcano
Greetings. I have been playing with the developers guide example [1] for 
embedding LO inside a Java window (Swing toolkit). The example works on 
a Windows host, but on Linux I found the following problems (in the 
order I found)


1- When the host Java application is running on a Wayland session (Java 
Swing is still an X11 program), there is a crash. IIRC LO still is a X11 
based application (or at least the Fedora compiled version is using the 
X11 GTK back-end)


2- Switched to an X11 desktop session, there was no crash this time, but 
the document was not shown embedded on the Java window, it was a 
floating window with no window controls, unresponsive to the user.


3- Run the same application with the environment variable 
SAL_USE_VCLPLUGIN=gtk in order to force the LO GTK2 back-end. The 
document is embedded on the Java window as expected, but keyboard input 
is not possible on the document or the controls, mouse actions works, 
for example, I can change fonts using the mouse, but can't write 
anything on the font combobox nor the document. New LO dialogs opened 
from that document, keyboard input works.


4- Trying with SAL_USE_VCLPLUGIN=gen and keyboard input now works, but 
with the outdated look of that LO VCL backend :(


So now the possible reasons that came to my head for each case:

1- Some confusion between Java being X11 and LO trying to do some 
Wayland thing?


2- Java has a GTK Look and Feel/theme that loads GTK2 (the example 
application does not load that theme) , I am under the impression that 
if LO is loading GTK3, they are on different processes, so should not be 
any conflict here.


3- Now both processes should be using GTK2, but the problems with 
keyboard input is a blocker


4- Everything running without conflicting libraries/protocols (Wayland 
vs X11 or GTK3 vs GTK2) and work, but the look and feel!!


Now, when running the example with a no inline option, everything works 
fine, even when GTK2 and GTK3 are mixed. Wish to have an option to 
create the new document top level window as a child of the Java window, 
it is a pain for user that the document can go to the back of the 
"caller" window. Any hints if this is possible between two processes 
like Java and LO?


Any other developer here embedding LO in another applications on Linux 
that can give me any pointers? Before starting to look on enhancing LO 
embedding on Linux, is there any technical reasons things are 
working/non working this way?


Thanks in advace.

[1] 
https://api.libreoffice.org/examples/DevelopersGuide/OfficeDev/DesktopEnvironment/

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice