Preferred framework for graphical stuff?

[Jean-Philippe Ouellet]

Hello,

Is the following statement from [1] still true re: preference for gtk over qt?

> As usual - python. As for toolkit - currently it is mostly in Qt
> (especially the current qrexec confirmations). But since the long term
> goal is to implement new Qubes Manager in GTK and to add GNOME support,
> GTK is also ok. If it doesn't matter for you, I'd choose GTK.

[1]: https://github.com/QubesOS/qubes-issues/issues/953#issuecomment-219311193

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Generally yes, especially the part about choosing GTK ;) Since then
we've moved to default Xfce, and GTK will be more consistent here.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYM7gJAAoJENuP0xzK19cssd0H/3/0Q0QrYMeP+aWzDy16ZQyM
oi2qB1c11dWtaRXNtLmlU5QHK+zo/oZFA/esNClPWRa/8OA9vLg8o3BHPv4r/0TY
mb1Yk9CNKz48Uf8GmbI9dKm2yuwugZ2vukJoHkxSmBgMktlKsLtZrbV6S9VB/d0U
Yw+Se+6CR3AQNVkx4ZNLO+FWyMYHKslpra+4nTBYPD6P6ElefgjV9StOFTmRiV40
58PFYEDL1psJG3rfdS0X/Qg9TsszjUY9krrBfXRy4eYVsSI6J1J5mVIpBt8De6Bz
FWlVkxMKnNbalKiBXdyHqE8D+7BlG4zRT6f/ZgX6l94WD9NwuQaeHMMVsWM55fI=
=50A6
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Mon, Nov 21, 2016 at 10:14 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> Generally yes, especially the part about choosing GTK ;)

Noted.

> Since then we've moved to default Xfce, and GTK will be more consistent here.

Are you saying that Xfce as default is the long term plan now?

Or saying that there will be more consistency between {GTK in Xfce vs.
GTK in Gnome} than {Qt in Xfce vs. Qt in Gnome}?

I don't understand.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Both Gnome and Xfce use GTK widgets, so GUI parts done in GTK (vs Qt)
are more consistent with the rest of desktop environment.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYM8XnAAoJENuP0xzK19csMngH/iABInH1oeV7TBS6CfGN7F38
2yuIVZ1AsoTupWzVykQnIzbZ933XqjbD1rXW/4M6GoJQRjteVMc/zcc5oL7c/Tv9
Suoyaho6+Eotv76Oz3GGk/mNYAEY5FRqfwIc341v0WLxXjfj6tFX/ue11ILNXeJX
Cgb5bMqUIBm15drZbIU0I8lp+Ce4ge+oL8rvQ+NTGXDk7zJ/ZlZkRKrG+K+TGDtF
U4HIEqdwfEtBmBNe1zvBjhiBBS85aSJP2XVaE1gj8uSdLH8EcGJ67BRQn0S+GMaP
cOeboDwmupZGnZJeGr3BpYECqxezrLDhLT+pRqePh01+NjSo/jgXr8PZYzDXq88=
=GK6T
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Mon, Nov 21, 2016 at 11:13 PM, Marek Marczykowski-Górecki

<marm...@invisiblethingslab.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Nov 21, 2016 at 10:57:25PM -0500, Jean-Philippe Ouellet wrote:
>> On Mon, Nov 21, 2016 at 10:14 PM, Marek Marczykowski-Górecki
>> <marm...@invisiblethingslab.com> wrote:
>> > Generally yes, especially the part about choosing GTK ;)
>>
>> Noted.
>>
>> > Since then we've moved to default Xfce, and GTK will be more consistent here.
>>
>> Are you saying that Xfce as default is the long term plan now?
>>
>> Or saying that there will be more consistency between {GTK in Xfce vs.
>> GTK in Gnome} than {Qt in Xfce vs. Qt in Gnome}?
>>
>> I don't understand.
>
> Both Gnome and Xfce use GTK widgets, so GUI parts done in GTK (vs Qt)
> are more consistent with the rest of desktop environment.

[1] has made me give some more thought to this. Yes, GTK is the
natural choice for things wishing to be first-class citizens in Gnome,
but this may not be the strongest consideration long-term.

Moving to Gnome has stagnated, and is a very low priority [2].

With the planned disaggregation of the GUI into its own domain [3],
iteration in the desktop experience of Qubes becomes much easier, and
I think it's quite reasonable to consider that Gnome may not be the
only final target.

I think it is also worthwhile to consider the difference in experience
between Qt in primarily-not-Qt environments, vs. GTK in
primarily-not-GTK environments. On other non-linux platforms, Qt is
much better integrated into the native desktop UX than GTK. This is at
least true on Windows and OS X, and even Genode has native support for
Qt which continues to improve. This may may sound irrelevant now, but
I think is less so post-GuiVM.

FWIW it seems that peoples' complaints about the current Qt
qubes-manager in Xfce have nothing to do with it being Qt instead of
GTK.

I'd also like to bring attention to some relevant 3rd party
discussions on this: [4]

I believe that limiting the inputs to this decision to "Gnome means
GTK, we plan to eventually target Gnome, therefore let's use GTK" may
be short-sighted.

Thoughts?

[1]: https://groups.google.com/d/msg/qubes-devel/jDHiZ9nhzIc/5DIRzcOUCwAJ
[2]: https://github.com/QubesOS/qubes-issues/issues/1806#issuecomment-280281571
[3]: https://github.com/QubesOS/qubes-issues/issues/833
[4]: https://askubuntu.com/questions/281092/why-is-canonical-choosing-qt-over-gtk-for-unitys-next-generation

[Joanna Rutkowska]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

These are all good points, JP. But I think it's difficult and often
counter-productive to try to over-generalize or make code over-portable "just in
case". So, I think that the choice of the GUI framework should be dictated
primarily by the requirement to make our GUI stuff first-class citizens of
whatever Desktop Environment we want to be the official one in the upcoming
release. At this time we believe that for both 4.0 and 4.1 this will be Xfce4.
The next criterion should be ease of development/integration with current code.

Perhaps for Qubes 5.x we will want to switch to some yet-unknown desktop
environment, but then, chances are high, we will want to rewrite any GUI stuff
anyway. This is because the new environment might use different UX paradigms, or
maybe in a few years time the general UX paradigm will change. So, ISTM, trying
to plan too much ahead (which framework/lang to use for GUI/UX), might often not
be worth it.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJY4XAaAAoJEDOT2L8N3GcY7WMP/0RLgL7xxKjoSaKznPE0jiKy
v8djdN4lEEhZEESg3Zc5H0LtTa/4ECfuThG5VqCEiCcry1IvzPhwInU8AH1JWoyn
6wRK0ogsy3tggC/90OHmJpKCJzaunD7XEUa5Gme7weDPTHWpbhnrh9UOEQzEJ4EH
bzKbgnjxR8uuoj0xOeo32gFkN3xQ6Bu0LxmeiWBtVbORGd90E8b/M7dlq9WY2g0l
Sj31ZMCSi6ugPrbW+EgCoLm/bqRMMQFKZBlVZEwF19/prrUUqxCmY9KAZbGFENMe
MHSCAFAlXfAyiqA3xkZs8uaTLSq2WdK+jwaJqmk4rlBC9wlKOWLdldo413rT8Lvz
TwHzSfLAVauxe1p2ej5HoNje8KOnwtnC52vIwaRuBOFr8x+oeQlRLZgPGUlxmYVn
Xyt48CEis2bG18XuRgmN1f/QBw2F/FY0yQvawQgOlnJgpMc4tL5xjzrEvXHJSGxq
bqwyn8NYAiWqjkZ1id11wLV8OyFe5iIi1rwUxZxBl8Y2wCaptnHzYTcHkTkQSy11
m5fh9BB8iohWyNMGCBSeXLTqoyO9AYjaHj4dKa37KF+oRzf/LOd2RZEx+Y+NVj3f
mDv85+0/mAu4A3fmAVtDngyVdtEPCTbgnRzeLlTu8tnHNEI2/qAubCDUJbh7e7Sl
Ez7Zu1x9heFBg/1wzaZD
=fQYz
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

> I think it's difficult and often counter-productive to try to over-generalize or
> make code over-portable "just in case".

Noted. I certainly agree with that principle in general. [1] :)

[1]: http://opensslrampage.org/post/83031733755/remove-support-for-big-endian-i386-and

> So, I think that the choice of the GUI framework should be dictated
> primarily by the requirement to make our GUI stuff first-class citizens of
> whatever Desktop Environment we want to be the official one in the upcoming
> release. At this time we believe that for both 4.0 and 4.1 this will be Xfce4.
> The next criterion should be ease of development/integration with current code.

Makes sense.

> Perhaps for Qubes 5.x we will want to switch to some yet-unknown desktop
> environment, but then, chances are high, we will want to rewrite any GUI stuff
> anyway.

The reason I raise this discussion is in hopes of reducing the
likelihood that we find ourselves in a position where we wish to
re-write things in the first place.

If you believe it is inevitable, then I agree that optimizing for the
next concrete plan makes the most sense.

> This is because the new environment might use different UX paradigms, or
> maybe in a few years time the general UX paradigm will change. So, ISTM, trying
> to plan too much ahead (which framework/lang to use for GUI/UX), might often not
> be worth it.

Noted. The current plan sounds good to me too then.