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

[ikey]

On 20/02/15 22:18, Andrzej wrote:
> On 20/02/15 15:10, ikey wrote:
>> So, that thread hit reddit. Time to make rules clear on how I'll
>> approach this port.. Or rather to clarify my position :)
>>
>> This will be a *like-for-like* port. This does not mean taking a
>> look at GTK3 and saying "oo shiny" and using things *just because*.
>> So that means no patch introduced by this initiative will seek to
>> introduce CSDs or redesigns to apps. That's the domain of the XFCE
>> project only.
>
> That is a good direction. Big questions are:
>
> 1. Do we support Gtk2 in the same codebase? Currently some libraries
> allow that (e.g. libxfce4-panel) but this is rather limiting and
> difficult to maintain.
>

IMHO kill it with fire. #ifdef /* ABI BREAK*/ FTL.

> 2. Do we want to be able to distribute&install Xfce4 and Xfce5
> simultaneously? IMHO this should be possible so that we don't force
> users down the "Gnome2->Mate" path, in case if users ended up being
> dissatisfied with the port.

Not my call but I'll just point out I'm calling the /effort/ xfce5,
as a development codename on GitHub, bout it. Prolly easier to do a
4.14

> I would recommend bumping major revisions, SONAMEs, and renaming at
> least core components (xfce4-panel->xfce5-panel). If someone wants to
> maintain and distribute Xfce4 that should be possible without massive a
> renaming effort (like the Gnome2->Mate one).
>

So again not my place to speak on that one but feels little different to
me than having #ifdeffests all over the place, by permitting for co
installable XFCEs. My thoughts personally would be one then updated from
the GTK2 XFCE to the GT3 XFCE..

>> 2) One whacking great deprecation I can't mentally avoid, so will now
>> mention.. GtkImageMenuItem. That fella is gone. What do we want to do
>> about this? (Alternatives include just dropping images in menu items
>> or forking it into libxfce4ui)
>
> Talking about my own experience with porting the panel
> (andrzejr/wrapper3 branch[1]), there were some performance issues with
> GtkImageMenuItem's (CPU use, flicker), but that could have been due to
> issues in our code. Otherwise, GtkImageMenuItem may be deprecated but
> Gtk devs promise not to remove any APIs during Gtk3 development cycle so
> I have no problem with using it.
>

Hmm, not experienced it myself. Personally I'm totally OCD about seeing
deprecation warnings, so better to do the work *now* than later.

>> 3) Ok more than a couple. :) GTK_STOCK* usage is also deprecated some
>> time now, so I may have to harass you all on IRC about which icon names
>> to use. Basically named icons are used everywhere now. :)
>
> This seems OK with me, assuming we can make this change transparent to
> users (i.e. icons are still working).
>
> I found that the difficult and/or annoying bits fall into following
> categories:
> - switch to Cairo drawing and associated change in coordinates
> calculation (some changes were non-trivial)

Better drawing hierarchy ;) Back-to-front on a single context for all
Gdk windows? <3

> - different treatment of widget backgrounds, especially with
> GtkPlug/GtkSocket

True. But those have always been evil anyway.

> - dropped support for some X11 specific Gdk functions - parts of systray
> had to be ported to plain Xlib.

Which things? I've written an x11 tray even in Vala.. o_O In fact budgie
has the gnome-panel version.

> - theming stuff, it is just different and occasionally new mechanism
> does not provide functionality available before.
> - countless minor API changes ("because we can") - this may look like
> just an annoyance but it makes writing and maintaining Gtk2&3 compatible
> code difficult.
>

So "because we can" is not a reason, and I'd like to see which APIs you
mean that were changed "because we can". I'm sure its "because there was
a good reason"

> Overall, porting was fairly easy but there were many little changes and
> occasional roadblocks. Some of the problems (performance, background,
> context menu positioning) were not solved, which was the main reason we
> postponed gtk3 port of the panel until the next release.

Well, now's as good a time as any =P Concurrent development ftw.

  -ikey
>
> [1] http://git.xfce.org/xfce/xfce4-panel/log/?h=andrzejr/wrapper3
> Unfortunately, it is not up to date with the current master branch.
>
> Thanks,
> Andrzej
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev