pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] Deprecated libgnome-keyring


From: Petr Kovar
Subject: Re: [Pan-users] Deprecated libgnome-keyring
Date: Sat, 3 Jun 2017 16:08:53 +0200

On Wed, 31 May 2017 01:45:34 +0000 (UTC)
Duncan <address@hidden> wrote:

> Detlef Graef posted on Mon, 29 May 2017 20:24:01 +0200 as excerpted:
> 
> > the libgnome-keyring library which is used when Pan is build with the
> > option --enable-gkr is deprecated. During the build process I get
> > warnings [...]
> 
> > The suggested new libraries to replace libgnome-keyring are:
> > 
> > https://developer.gnome.org/libsecret/ and
> > https://developer.gnome.org/gcr/
> > 
> > I have a patch (which has to be tested) to remove dependency on
> > libgnome-keyring.
> > 
> > libsecret and/or gcr are part of Gtk+ 3, this means Pan cannot be run
> > with the patch above applied and Gtk+ 2.
> > 
> > Pan doesn't start if it is build with libsecret, gcr and Gtk+ 2. The
> > following error occurs:
> > 
> > (pan:20683): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and
> > GTK+ 3 in the same process is not supported
> > 
> > The question is if the patch should be applied now or should we wait
> > until libgnome-keyring is removed?
> > 
> > How long will Gtk+ 2 will be supported?
> 
> Not being a dev, it's possible my knowledge of pan's gtk3 support status 
> is now outdated, but last I knew, building against gtk2 was still 
> recommended, as there were still mysterious runtime errors and various 
> GUI glitches when built against gtk3.

Yep, though I'm wondering to what degree this is still the case.
Anyone running gtk3 here can comment?
 
> And building against gtk2 is what I'm doing here, using a long customized 
> live-git fetching ebuild from my overlay, based on the old gentoo live-
> git pan ebuild I don't believe it ships any more.
> 
> But I've always built with the keyring support off as it pulled in too 
> many unwanted gtk/gnome deps I didn't otherwise use.
> 
> Meanwhile, after just checking the gentoo main-tree ebuilds, gentoo at 
> least has continued to force a gtk2 build (--without-gtk3), the comment 
> in the (0.141) ebuild saying "gtk3 support is still not ready (follow 
> what Fedora does)".  But it's quite possible that hasn't been reviewed in 
> awhile.
> 
> So the question from that is what Fedora is currently doing?  Are they 
> still forcing gtk2?

Fedora does the very same as what you say, but then again, it might be
mostly due to historical reasons.

How would regulars here feel about switching to gtk3 by default? That way,
it could get more attention from people who run the default configuration,
that is, in case there are outstanding (major) issues with the gtk3
support. 

> And the larger question of course is how long the distros are likely to 
> continue to ship gtk2?  And on that, last I knew, Firefox still hard-deps 
> on gtk2, even when built with the optional gtk3, so at least distros that 
> ship a shared-lib firefox will continue to need gtk2 for the time being.
> 
> Meanwhile, what's the status of the various gtk-based desktops?  I'm a 
> kde/plasma desktop (but not so much else these days) guy so haven't been 
> keeping track, but last I knew, at least one of them had no plans to go 
> gtk3... or wayland.
> 
> So gtk2 might well be around for awhile.  But I don't believe anyone's 
> doing a gtk2 wayland port, which means anything stuck on it will be stuck 
> to x11, and will likely eventually be handled by xwayland on wayland 
> based desktops and systems.
> 
> Meanwhile, that "deprecation" only applies to gtk3, correct?  Nobody's 
> killing the gtk2-based lib, right?  If so then it really does appear to 
> be just one more aspect of the larger gtk2/gtk3 question, which is 
> obviously how I treated it, above.

As for libgnome-keyring, we could continue build it together with gtk2
(when gtk2 is enabled), but gtk3 would always be built with the new
libraries (libsecret & gcr).

Cheers,
pk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]