Configuring/compiling gbuffy on modern Debian systems.

Duncan 1i5t5.duncan at
Thu Sep 14 07:45:26 BST 2017

A. F. Cano posted on Tue, 12 Sep 2017 16:56:08 -0400 as excerpted:

> 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.

> 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.

> [Many of the other notifiers] don't have the simple
> one-button-per-mailbox interface I want.

Thanks.  I understand your want somewhat better now, and altho I can't 
specifically help with it further, I can certainly identify with the 
frustration of having something that works like you want, and then having 
it effectively ripped away from you as that code is abandoned and newer 
so-called alternatives... aren't!

Because for many kde users including me, that's exactly what happened 
with the kde3/kde4 transition, with the promise to keep kde3 supported as 
long as there were users making it even worse!

While the kde4 to frameworks/apps/plasma5 hasn't been as bad, because at 
least this time they let apps and their developers transfer at more or 
less their own natural speed (tho kdelibs4 support is apparently on a 
limited timeline now), there's still one kde4 app, the now abandoned 
superkaramba, that I've yet to replace.

The official word is that it's possible to script all that with qtscript, 
etc, now.  The /problem/ is that yes it may be /possible/ but unlike 
superkaramaba, there's no nicely packaged documentation/tutorial for how 
to do it, in particular, one that demonstrates how to create your own 
graphs, digital readouts, etc, and color/font/style/position them as 
necessary, without already knowing javascript, the way the superkarmaba 
documentation did for it.

While I've yet to look into it in detail, I imagine I'll have to learn 
the configuration and make do with konqi or gdesklets or the like, tho 
there's a narrow possibility I may be able to study enough of the various 
plasma5 plasmoids to figure out how to adapt them to do most or all of 
what I need, including custom displays for all the mobo-specific temps, 
fan speeds, cpu stats for the specific number of cpucores, etc, that I do 
with superkarmaba.

Totally different app for a totally different purpose, but what I'm 
saying is that I sure can identify with the pain of having a working 
solution, and then having it break because the old code is abandoned and 
nothing new provides a sufficiently similar or even workably close 

OTOH, in the kde3/kde4 transition, I ended up scripting up my own hotkey 
popup menu solution in bash (because that's what I know) and running it 
in konsole windows, with sxhkd listining as the launcher, because AFAIK 
they never /did/ get global multi-key hotkey chaining working in qt4/kde4, 
like it worked in qt3/khotkeys3.  I needed one or a very few trigger 
keys, with the ability to popup a recursing menu, each time another 
hotkey level was pressed.  Because I hacked up my own solution for kde4, 
I was able to carry it forward with only very minor modifications to 
plasma5. =:^)

Unfortunately, the coming jump to wayland's likely to kill that as an 
alternative, because only kwin, as the compositor, is going to be able to 
listen for global hotkeys, due to the better security in wayland.  
Hopefully the kde/plasma global hotkey solution in wayland ends up being 
flexible enough to let me hook into it as needed, and hopefully if it 
continues to work that way, they don't up and ruin a perfectly working 
solution, as they did with the kde3/kde4 transition.   Because I run a 
lot less kde after the kde4 fiascos left me little choice but to switch 
to something non-kde for a working solution, than I did before, making it 
a lot easier to switch away for the desktop too now, if I decide I need 
to.  I guess time will tell...

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

More information about the kde mailing list