use ozone and aura on x11 without gtk2

[Marius Cirsta]

 Hi,

 I'm currently trying to do a build of chromium for x11 but without gtk2. So far my investigations have shown that a linux_ui.h is called which defines an abstract class that only the libgtk2ui implements for now. I'm just curious how the wayland implementation works , is there a way to build for x11 without this gtk2 dep ?

 Also if there is a better place to ask this please point me to it.

 Thanks.

[Elliot Glaysher (Chromium)]

The long term intention was to actually have a libgtk2ui.so that was dynamically loaded at startup (and which would have been cold swappable with something like libgtk3ui.so, libeflui.so, etc). This never happened. If you try to run desktop linux chrome while trying to just comment out setting the LinuxUI instance, you'll probably find new and delightful crashes and bugs.

Also, I wasn't aware that we had a desktop linux wayland version, or that you could run the desktop linux port on top of ozone. I thought those were only from chromeos.

[Kyle Charbonneau]

Hi Marius,

Were you trying to do a Ozone X11 Desktop Chrome build or Chrome for Chrome OS build? Essentially, did your GN args have target_os = "chromeos" in it?

If you did not have the target_os arg then you're trying to do a Desktop Chrome build. Unfortunately, Desktop Chrome doesn't work with Ozone. There is a partly finished implementation of Desktop Ozone but it doesn't work. You'll just get build errors if you try to compile it. There is also an out-of-tree Desktop Chrome implementation using Ozone Wayland here. I don't know too much about it though.

Kyle

--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+unsubscribe@chromium.org.

[Hur, Joone]

There is a way to run content_shell under Wayland without gtk2.

Here is a CL to do it: https://codereview.chromium.org/2027943002/

This blog article may be helpful to understand how to build content_shell for Wayland.

https://blogs.igalia.com/tonikitoo/2016/05/18/chromium-content_shell-running-on-wayland-desktop-weston-compositor/

In case of ozone-wayland, we are able to run Chromium without gtk2 dependency.

https://github.com/01org/ozone-wayland

We also implemented a file-picker using WebUI, but the UI is quite simple.

Thanks,

Joone

--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+...@chromium.org.

[Marius Cirsta]

 Thanks for the great and prompt responses guys, it's much more than I expected. Also sorry if what I wanted wasn't clear, I'll try and make it clear now.

  I wanted to build the latest chromium I could find ( 54.0.2832.0 ) for desktop Linux with X11 and without any gtk2. This is because don't want to have the gtk2 libs in my system.
 
 For some reason following some of Kyle and other people's work ( good job by the way guys ) I thought that with all that refactoring and stuff Ozone on X11 would now be possible or at least easier. Of course I didn't really take into account that this could be for ChromeOS and not for desktop Linux.

 I don't have anything against ChromeOS but as a power user I prefer a desktop Linux distribution with KDE as my DE.

 I think I got the idea here, Aura ( or is it Ozone  ? ) relies on some abstract class ( found in  linux_ui.h ) that is then implemented by libgtk2ui. For some alternative toolkit ( I'm thinking about qt5 here ) you'd need to implement these methods just like libgtk2ui does and then then you could load the appropriate .so at runtime.

 Any estimation of how hard this would be ? To implement all the things libgtk2ui takes care of ( or at least the basic ones ). I might try and come up with something here for qt5. Also how stable would you say this interface is, could I count on it not radically changing ? One more thing, would this benefit a desktop Wayland port ? I'd really like it to be useful beyond X11 ?

 Thank you.

[Marius Cirsta]

 Also further attempts revealed that the problem is when you put "use_ozone=true" and you are building on Linux desktop, this results in several errors and doesn't yet seem to be supported.

On Friday, August 19, 2016 at 11:37:18 AM UTC+3, Marius Cirsta wrote:

[Elliot Glaysher (Chromium)]

On Fri, Aug 19, 2016 at 12:21 PM, Marius Cirsta <mfo...@gmail.com> wrote:

 I think I got the idea here, Aura ( or is it Ozone  ? ) relies on some abstract class ( found in  linux_ui.h ) that is then implemented by libgtk2ui. For some alternative toolkit ( I'm thinking about qt5 here ) you'd need to implement these methods just like libgtk2ui does and then then you could load the appropriate .so at runtime.

 Any estimation of how hard this would be ? To implement all the things libgtk2ui takes care of ( or at least the basic ones ). I might try and come up with something here for qt5. Also how stable would you say this interface is, could I count on it not radically changing ? One more thing, would this benefit a desktop Wayland port ? I'd really like it to be useful beyond X11 ?

LinuxUI is mostly used by views. Think of views as a widget set, aura as a window compositing framework and ozone as a low level get-pixels-to-hardware framework.

 

Actually implementing a qt version of LinuxUI shouldn't be that difficult, but making it cold swappable by desktop environment at startup was the blocker. (While we don't ship the configuration, we had a contributor who made sure that libgtk*2*ui was compilable under libgtk3, and I believe that's a build flag you can set on gentoo or something to enable that, though we don't test or QA that configuration.) IIRC, the problem is that chrome release builds are set up to be large statically linked blobs, and a library that was dlopen()ed wouldn't be able to reach into chrome proper to call chrome symbols.

That said, as long as you're fine statically linking whatever version of qt into your chrome binary, I don't know of any particular dragons that you'll encounter. (Famous last words). You might have to find a way to make qt play nice with a glib message pump, but other than that, you should be able to get everything self contained within a libqtui directory. You'll probably also want to do this in a non-ozone build, since ozone is a low level pixel output thing and the desktop port of chrome doesn't use it.

-- Elliot

[Marius Cirsta]

  In the meantime I also noticed that indeed if you disable remoting ( which seems to need gtk2 or at least its gn file says so ) the rest does work with use_gtk3 and so gtk2 is not needed now which is still something. There was one test still needing gtk2, I'll probably file a bug report for that one but other than that it actually worked.
 Anyway at least I learned a bit about chromium UI and it was interesting to see how it works.

Thanks.