Ethereal-dev: Re: [Ethereal-dev] Mac OS X (Jaguar) edition of ethereal

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 30 Oct 2002 23:32:48 -0800
On Thu, Oct 31, 2002 at 07:46:11AM +0100, ewitness - Ben Fowler wrote:
> At 9:52 pm -0800 30/10/02, Guy Harris wrote:
> >On Thu, Oct 31, 2002 at 06:35:32AM +0100, ewitness - Ben Fowler wrote:
> >> >...the only two GUIs for which there's support in the current CVS tree are
> > > >GTK+ 1.2[.x] and GTK+ 2.x; ...
> >[ big snip ]
> >
> >> or using a framework such as wxWindows which has support for multiple
> >> GUIs?
> >
> >wxWindows has support for *some* GUIs; unfortunately, it doesn't have
> >support for a GUI that I think would be of interest to many Ethereal
> >users, namely the KDE GUI.
> 
> It follows, unless I am misunderstanding, that to get a native
> Mac OS X Ethereal off the ground, I might start by putting steam
> behind an Ethereal-KDE project.

I'm not sure that'd be a better way to get a native MacOS X Ethereal
than just doing an Ethereal-Aqua project, as the KDE port itself
wouldn't help with Aqua, and the work you'd do to make Ethereal more
friendly towards KDE (atop which you'd do the KDE port) would probably
be the same as the work you'd do to make Ethereal more friendly towards
Aqua - i.e., it'd just be generic work for any toolkit.

> I believe that wxWindows works the way you outlined. It uses native
> widgets where they exist and adds 'generic' ones where they do not.
> This occasionally causes problems as in the case of the Spin Button
> Control (I hope that I have spelled that correctly) which I believe
> is native on few platforms.

Yes, it is; GTK+ and Windows both have a spin button.

We use the GTK+ spin button in, for example, the "Capture limits"
section of the Capture Options dialog box.

> I certainly see that. It looks like a process of evolution. If the milestone
> is 'Ethereal can use several GUIs' where are the inch-pebbles?

I don't know.

I could see several versions of the multi-GUI implementation, with more
stuff done in common code (perhaps providing a higher-level UI API, used
by common code, with multiple implementations for different toolkits and
toolkit+desktop environment combinations).

> I have mentioned that I would be happy ot work on a KDE gui, and I would
> also on a curses one. Would a move to wxWindows be a better starting off
> point?

I don't think a *move*, in the sense of "discard the GTK+ code entirely
and use only wxWindows", would be the right thing to do.

It might be interesting to have wxWindows be *one* of the GUIs we
support; when that's done, it might be interesting to see whether,
having done that, one has a better idea of how to do that higher-level
UI API, perhaps as an API like that of wxWindows (and also to see to
what extent the wxWindows version of Ethereal looks like a native
GTK+/Windows/Aqua version of Ethereal; I infer from your comment about
spin buttons that some wxWindows widgets might not behave enough like
the native widgets to make everybody happy).

> Should the directory structure for packet decoders be created first.

I don't know - I think Joerg Mayer was one of the people talking about
that, so I'll leave that question to him.

> An alternative to all this would be to stick with GTK and wait
> for that to be ported to other systems,

I don't know how long a wait that would be - and one reason for wanting
a native Windows version of Ethereal is that the GTK+ version has some
problems, some of which might be fixed if we ever get it working with
GTK+ 2.x, but others of which might be a consequence of using GTK+
rather than native widgets.

> assuming that there remains work to do on the meat of Ethereal?

I don't see a point in the near future - or probably even the
medium-term future - when there *won't* be work to do on the meat of
Ethereal.