Ethereal-dev: Re: [Ethereal-dev] Alternative GUI for ethereal

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Wed, 26 Sep 2001 00:05:35 -0700
On Tue, Sep 25, 2001 at 12:55:32AM +0200, Malte Starostik wrote:
> But, as a matter of personal taste, I don't like GTK's look&feel too much

GTK+ doesn't have *a* look and feel; it has a default one (which is very
Motif-like, so I can see why you might not like it...), but GTK+ 1.2 and
later are themable; see, for example:

	http://gtk.themes.org/

I think GTK+ 2.0 may have a different, and perhaps more attractive,
default theme.

But, in any case...

> I'm wondering if it would be possible to add this (once it's a little more 
> stable and complete) to ethereal's CVS tree?

...one reason why there's a "gtk" subdirectory is to leave room to add
support for other UI toolkits, such as Qt+KDE (a GNOMEified Ethereal
might also be interesting - and a bit easier, as we already have the
GTK+ support - and other possibilities include a native Windows version
and a curses version).

So I think it's a reasonable idea to add KDE support, although it
shouldn't require that developers have the KDE development development
toolkit installed unless they want to build the KDE version (and, for
that matter, it shouldn't require that they have the GTK+ development
toolkit installed unless they want to build the GTK+ version, although
it'll require the GLib development environment in any case), and the
configure script should allow you to specify whether you want the KDE or
GTK+ version built (or perhaps let you build both).

Note also that the process of moving all UI toolkit calls into the "gtk"
subdirectory is not complete, and that the packet list window
implementation will probably change significantly at some point (which
will involve Ethereal supplying a modified version of the GTK+ CList
widget, which would allow columns to be added, deleted, and moved
without destroying and re-creating the widget, and which would, instead
of copying the strings for all the columns, call a callback routine to
get the strings as they need to be displayed), which may, if QListView
can't be subclassed to provide a similar list view widget, require the
creation of a new widget (perhaps by copying the QListView widget, now
that Qt is GPLed; QListView lets you add columns at the right end of the
widget, but it doesn't let you add them at arbitrary locations, unless
I've missed something - and it doesn't have any "virtual column" notion
of the sort I mentioned.  By the way, what do you do if you want more
than 8 columns in a QListViewItem?).

I.e., be warned that the ground could conceivably shift out from under
you while you're developing this.