bug-mailutils
[Top][All Lists]
Advanced

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

Re: C++ & Hydrant


From: Jakob 'sparky' Kaivo
Subject: Re: C++ & Hydrant
Date: 09 Feb 2001 19:36:45 -0800
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

"Alain Magloire" <address@hidden> writes:

> > Yes, similar thing with GNUTS. You have things like a window_t and a
> > button_t and you tell the window_t to insert this button_t and if the
> > current backend is curses it is naturally implemented differently than
> > if GTK+ is the backend. OO-y in nature, with window_t and button_t
> > designed as opaque structures and families of functions associated
> > with them.
> 
> There are a lot and I mean a lot of toolkits/frameworks out there, old, good,
> bad, OO, non-OO, you name it exists.
> There is absolutely no way that GNUTS could gain acceptance.
> 
> But OTO, using GNUTS as the generic front-end to hydrant would be certainly
> worth the effort.  I do not know of any other toolkits that gives the
> possibility of using cursors as the backend or gtk+.
>
> It would be nice to use hydrant on consoles and still be able to get
> to the menus and on a windowing systems taking advantage of the fact
> to be able to display an inline image in a mime message.
> 
> So having a mean/lean/lightweight little toolkit to isolate ourselfs
> from the gui wars could be good as long as it stays focus on its purpose.

(trying desperately not to stray further into discussion or pros/cons
of C/C++...)

Yes, I think you've summed up quite nicely the idea behind
GNUTS. Toolkit independance, so curses works, GTK+ works, Qt/KDE
bindings are possible, and perhaps configuration so that user foo can
set his GNUTS apps to use the GTK+ backend so they blend in with his
GNOME desktop and user bar can use Qt backend so apps blend in with
KDE. I desperately do *not* want to make Yet Another Toolkit, I want
it to be (relatively) easy to support terminal and windowing systems.

> Speaking with my heart.

Appreciated, and noted.

-- sparky



reply via email to

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