Establishing GTK3 port "rules" (and some q.s)

ikey ikey at
Sat Feb 21 16:31:59 CET 2015

On 21/02/15 04:27, Steve Dodier-Lazaro wrote:
> On 21 February 2015 at 00:44, ikey <ikey at
> <mailto:ikey at>> wrote:
>     True. But those have always been evil anyway.
> They're an absolute necessity for user-driven access control and for
> securing a bunch of other applications. UI embedding is used on Windows
> 8 (and OS X, I suspect) to provide custom widgets in file choosers, it's
> used by Android to serve ads without exposing parent apps' UIs, and it's
> got a massive potential for building permission UIs within apps. I don't
> remember anything of the internals of Plug/Socket and am generally not
> qualified to discuss that stuff, but I do hope there's a replacement coming.
And that stops them from being absolute evil.. how? :) Never said they
weren't needed, just stating the fact they are utter evil. Also please,
never *ever* use the word "securing" in relation to xembed, that's just
a joke. xembed is a security nightmare and in all honesty should be shot
in the face with a broken up Katy Perry CD.

There are other ways of doing things, such as using libraries, and not
embedding at all. I understand Simon has thoughts on a Wayland compatible
solution in the future involving sub surfaces. For the time GtkPlug and
GtkSocket still exist, so there's no reason to look at a replacement
*yet* (GTK3 enabling != Wayland enabling)

- ikey
>     My personal thoughts are to go forward with a complete port. If the
>     future of XFCE is on GTK3, then why support GTK2 anymore.. ?
>     I can understand why a compat shim would be used in a dual-scenario,
>     but I'm not entirely sure any API #ifdef's are wanted here. :)
> I would assume it'd be easier to just keep 4.12 in its own branch and
> backport high/critical/blocker fixes until installs of xfce4
> (specifically 4) plummet. I believe that's what Andrzej meant?
> --
> Steve Dodier-Lazaro
> PhD Student
> University College London
> Free Software Developer
> OpenPGP : 1B6B1670
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at

More information about the Xfce4-dev mailing list