Re: [PATCH v2 08/10] gtk: require gtk+ 3.16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

----- Original Message -----
> > If need be, we could lower gtk3 requirement to 3.10 (droping wayland
> > support in this case). Afaik, 3.16 is going to make it in rhel7 as
> > part of regular desktop rebase.
> 
> I think we should continue to support older 3.x versions for a while.

I just sent a series to fix build with min gtk+ 3.10.

However, in general, I think it's reasonable for spice-gtk to follow the desktop schedule, especially now that regular rebases will take place for those in rhel. GL support requires recent kernel/graphics layer, and wayland requires recent gtk+, why would spice-gtk have to support all that with an older gtk+? Imho, it makes much more sense to use the modern desktop environnment instead of having workarounds to support the old versions.

> Dropping wayland isn't an option I think.  Is it possible to build
> with/without glarea support (depending on the installed gtk version) and
> hiding that from applications without too much fuss?  I.e. with the
> glarea widget being a child of the new gtkstack widget, can we swap that
> for a drawingarea and render the old-style egl way in case we find old
> gtk version, without that being visible outside spice-gtk?

I have spent some time trying to fit a manual egl window surface in gtk+. While it works pretty well on X, it turns out it is really hard to do the same thing on wayland. I managed to get some rendering displayed, but it was badly aligned, and full of flickering, and I couldn't find easy solution to all that. Then I decided to try gtkglarea and found out that it just worked. And since recent gtk+ is required for wayland, depending on gtkglarea sounds like the best move forward anyway. But anyone, feel free to fix gl support on wayland with gtk 3.10.

> Another reasonable option would be going for two git branches:  Using
> last weeks release as base for a stable branch and plan to do bugfix
> releases (possibly backporting support for new spice protocol features
> too) for a year or two.

sure, although if we can avoid it, it's easier.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]