Configuring/compiling gbuffy on modern Debian systems.

[Alec Bloss]

Quite curious to see a GTK discussion come up here (off topic)

I haven't personally used gbuffy, but it is an abandoned project, and
hasn't been maintained for quite some time. 0.2.6. is the most current
stable release.

But I can speak about the GTK1 dependency issue. You could technically port
gbuffy to use GTK2 or newer. However that is not my area of expertise and
it is likely not worthwhile. There are alternatives to gbuffy as mentioned.

GTK1 (any GTK1 version) will not compile on a modern Linux system. There
are many reasons for this. Last winter I started updating it for reasons
not relevant here. Between different compiler standards and such it is
extremely time consuming and painstaking. It is even worse than updating
QT2 (which I do have a working fork of). Even if GTK1 would compile (which
even my fork of GTK1 doesn't compile completely yet), there are other
issues such as freedesktop.org compatibility, etc. that would have to be
considered. I haven't specifically looked at gbuffy source code but it's
old enough to have these sort of issues. In addition, even with an updated
GTK1 library, gbuffy would likely need to have some work done as well.
While legacy X11 applications can usually be compiled against X.Org and
will run on X.Org, there are issues with it still. There are no working
updated GTK1 ports that I am aware of. Keeping legacy versions of libraries
side by side with newer ones is often a bit of trouble as well.

Essentially what I am saying is it is not feasible to use a GTK1 based
program on a modern Linux system. But thanks to open source, if you are so
inclined you could take the task on to port to a newer GTK version or write
a replacement for gbuffy.

Best of luck!

On Sep 12, 2017 8:06 PM, "A. F. Cano" <afc at shibaya.lonestar.org> wrote:

On Mon, Aug 28, 2017 at 01:24:40AM +0000, Duncan wrote:
> ...

> And there's all sorts of other mail notifiers available, so the question
> is, why are you trying to install something that old, unsupported,
> security-vulnerable and inconvenient to install, when there are so many
> other alternatives available?  What's so special about gbuffy that you
> /must/ use it instead of some other alternative that's still available in
> your distro's repo for a far simpler install?

It was exactly what I wanted.  A simple list of buttons that I can have
in a corner of the desktop and when I click the one that represents the
list I want to read it launches a konsole window with mutt in it.

> FWIW, the gbuffy descriptions I could google said similar to xbiff/
> xbuffy.  On gentoo (which I use) simply doing a package search, including

I've installed or looked over all the packages you mentioned, but only
xbuffy gives me that interface, so it looks like that's what I'll have
to go with, even though the font looks horrendous compared to gbuffy,
the config file is totally different and I'm still having issues getting
it to behave the way gbuffy did.  Some of the issues really look like
bugs, such as starting mutt in send mode in some cases, even when given
a mailbox file or doing the same when what it should do is open the main
incoming mailbox.  I'll have to make sure it's not an issue with my
config file before filing bug reports.

> description, on "biff", returns a number of alternatives, some console,
> some X-based.  Debian is said to have a larger package repo than most
> distros so it's likely to have these and more:
>
> * kbiff (kde-based, making it the actual on-topic one =:^)

Interestingly, this one is not in Debian.

> * gnubiff (gtk3-based, with a gtk2-based version also available, likely
> the most direct actually still available in the repo alternative to
> gbuffy)

The gnubiff window is way too big and obtrusive to keep open.

> * xbiff
> * hap (terminal-based biff replacement)
> * asmail (similar to xbiff, so X-based)
> * wmbiff (windowmaker dock applet)

All these don't have the simple one-button-per-mailbox interface I want.

> ...

In any case, thanks for replying.  I'll keep trying to configure xbuffy
to behave like gbuffy did.

Augustine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde/attachments/20170912/7fb6a9ea/attachment.htm>