I used claws-mail 3.7.5 under x64-macos for quite a while and it doesn't seem to be unstable so I figured I'd try to get the prefix ebuild in better shape for others to enjoy it as well ;) After talking with ABCD and others on #gentoo-prefix I came up with the following diff: --- ../../../../../portage/mail-client/claws-mail/claws-mail-3.7.8.ebuild 2011-03-06 05:32:42.000000000 -0800 +++ claws-mail-3.7.8.ebuild 2011-03-15 18:11:59.000000000 -0700 @@ -13,8 +13,8 @@ SLOT="0" LICENSE="GPL-3" -KEYWORDS="alpha amd64 hppa ppc ~ppc64 sparc x86 ~x86-fbsd" -IUSE="bogofilter crypt dbus dillo doc +gnutls +imap ipv6 ldap nntp pda session smime spamassassin spell ssl startup-notification xface" +KEYWORDS="~x64-macos alpha amd64 hppa ppc ~ppc64 sparc x86 ~x86-fbsd" +IUSE="bogofilter crypt dbus dillo doc +gnutls +imap ipv6 ldap nntp pda session smime spamassassin spell ssl startup-notification tray-icon xface" COMMONDEPEND=">=x11-libs/gtk+-2.6:2 pda? ( >=app-pda/jpilot-0.99 ) @@ -77,8 +77,8 @@ $(use_enable spamassassin spamassassin-plugin) \ $(use_enable bogofilter bogofilter-plugin) \ $(use_enable smime smime-plugin) \ - --docdir=/usr/share/doc/${PF} \ - --enable-trayicon-plugin \ + $(use_enable tray-icon trayicon-plugin) \ + --docdir="${EPREFIX}/usr/share/doc/${PF}" \ --disable-maemo ${myconf} } @@ -111,11 +111,11 @@ doexe tb2claws-mail update-po uudec uuooffice || die # kill useless plugin files - rm -f "${D}"/usr/lib*/${PN}/plugins/*.{la,a} + rm -f "${ED}"/usr/lib*/${PN}/plugins/*.{la,a} } pkg_postinst() { - gtk-update-icon-cache -f -t "${ROOT}"/usr/share/icons/hicolor + gtk-update-icon-cache -f -t "${EROOT}/usr/share/icons/hicolor" UPDATE_PLUGINS="" for x in ${PLUGIN_NAMES}; do @@ -133,5 +133,5 @@ } pkg_postrm() { - gtk-update-icon-cache -f -t "${ROOT}"/usr/share/icons/hicolor + gtk-update-icon-cache -f -t "${EROOT}/usr/share/icons/hicolor" } It compiles fine and I'm running it now.
Can you give some insight on the implications of that tray-icon thing? The maintainer (Cc-ed) might want to know if it's useful outside OSX, for example.
libtool fails to link trayicon.o and exits with a bunch of undefined symbols. This is for versions 3.7.5 and 3.7.8. I'm assuming .6 and .7 as well but I don't know from experience. Instead of trying to fix the linking issue I just disabled it. My ebuild-fu is stronger than my C-fu ;)
Sorry, were you asking what the tray-icon does? I don't think I've actually used the tray-icon plugin on my other machines so I can't tell you from experience. Here's the page for it: http://www.claws-mail.org/plugin.php?plugin=trayicon
ok, from that I get the impression it just won't work on any other window manager than the one it needs (GTK/Gnome?)
I would be fine with the trayicon USE flag, but in general think it is not needed. Prefix team, please do any additions in the main tree you need to do.
Might trayicon be better suited as a plugin in a separate ebuild ala mail-client/claws-mail-archive, mail-client/claws-mail-cachesaver, etc etc.. ?
I think we should disable the trayicon just when it makes no sense, without USE-flag.
(In reply to comment #7) > I think we should disable the trayicon just when it makes no sense, without > USE-flag. Do that.
@Grobian: did we ever merge this?
no
(In reply to comment #7) > I think we should disable the trayicon just when it makes no sense, without > USE-flag. Under which conditions should it be disabled then? In prefix in general or switch it with a gnome use flag?
It depends on the environment, indeed. OSX doesn't have a "tray". Windows and GNOME do. I believe KDE has one as well. I'm actually not sure what the configure thing does. Perhaps it's smart enough itself, but since it was disabled by OP, I'm affraid not.
(In reply to comment #12) > It depends on the environment, indeed. OSX doesn't have a "tray". Windows > and GNOME do. I believe KDE has one as well. I'm actually not sure what > the configure thing does. Perhaps it's smart enough itself, but since it > was disabled by OP, I'm affraid not. So $(use_enable !kernel_Darwin trayicon-plugin) then?
I'm sorry, but I'm going to close this bug, because a lot of time went by and I think it needs a re-evaluation. Thanks for the patch and work though.
