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

[Liviu Andronic]

On Fri, Feb 20, 2015 at 11:18 PM, Andrzej <ndrwrdck at googlemail.com> wrote:
> 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.
> 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).
>
Actually this eerily reminds me of a request I've been making over the years:
http://article.gmane.org/gmane.comp.desktop.xfce.devel.version4/19053

In LyX there is a compile-time option that allows to freely have two
versions of LyX installed independently on the same system. So for
instance, you can:
./configure --with-version-suffix=-svn

And then all relevant folders/filles will be uniquely appended with
`-svn` string. This configures SVN LyX to use 'lyx-svn' instead of
'lyx' for the binary, '.lyx-svn' for the home profile folder,
'lyx-svn' for /usr/local/share/, etc.

Perhaps a similar arrangement could be made for Xfce, too, allowing
for instance to have an installation of 'xfce4-panel-gtk3'...

Regards,
Liviu


>> 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.
>
>> 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)
> - different treatment of widget backgrounds, especially with
> GtkPlug/GtkSocket
> - dropped support for some X11 specific Gdk functions - parts of systray had
> to be ported to plain Xlib.
> - 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.
>
> 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.
>
> [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



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library