On Fri, Nov 28, 2014 at 11:43:36AM -0800, Guy Harris wrote:
>
> On Nov 28, 2014, at 11:23 AM, Stephen Fisher <sfisher@xxxxxxx> wrote:
>
> > I've started tinkering with the possibility of making a curses text
> > based GUI for Wireshark (cshark, I suppose). I started by making a
> > new directory under ui/ for it and creating dummy functions for
> > things that the main code base runs (such as file.c) to display
> > things in the user interface.
>
> Actually, I'd expect a curses version of Wireshark to use file.c.
> It's sort of "the file handling code for Wireshark", in the "just
> Wireshark, not TShark" sense of "Wireshark".
Sorry, I meant dummy functions (until they're implemented) for routines
that file.c calls such as packet_list_resize_column() etc.
> > In doing so, I've realized that although some of our user interface
> > code has been separated into the ui/ directory from the ui/qt and
> > ui/gtk, there is still a lot to re-implement to support another user
> > interface beyond the actual display routines.
>
> What are some non-display parts of the code that needs to be
> reimplemented?
The most recent files I was looking at were ui/qt/file_set_dialog.cpp
and ui/gtk/fileset_dlg.c. The Qt code was written as a drop in
replacement for the GTK code, so it uses the same function
name/parameters, e.g. fileset_dlg_add_file(), which is in both
fileset_dlg.c and file_set_dialog.cpp. (The Qt version calls
fs_dlg->addFile() where fs_dlg is a FileSetDialog since its C++ of
course.)
The type of issue I'm seeing is that the fileset_dlg_add_file() in the
GTK code base and FileSetDialog::addFile do the same thing, but in
different ways, and repeat some of the same logic if not code. The GTK
version uses g_strdup_printf() to create a time/date string and the Qt
code uses QDateTime::fromTime_t. After that identical functionality, it
moves to the GUI specific code. With the current source code layout in
the ui/ sub-directories, I would need to code a time/date function again
in the curses directory and then the "GUI" code to display the window on
the screen. It would be better (if we were to move in this direction of
supporting multiple user interfaces) to have one entry point to the add
file feature and then only do the non-GUI part once and then call the
GUI routines based on which GUI we're running under.
Note: I'm not criticizing the way the Qt replacement for GTK has been
done so far. I can tell a lot of hard work has gone into it. And it's
being done the right way if we're just going to swap out GTK with Qt.
I'm bringing this up to see if we want to change the direction we're
moving to support not just Qt.
> > One major issue would be implementing things like the packet list.
> > We currently extend the GtkTreeView/GtkTreeModel in GTK and at quick
> > glance it appears that we extend QTreeView/QAbstractItemModel in a
> > similar fashion for Qt. We would need to create our own
> > model/view/controller code and then just display the view using
> > GTK/QT/curses/etc routines.
>
> That's one place where I'd be willing to have the code be
> UI-platform-dependent, because it's performance-critical, especially
> when reading Really Large Capture Files - as far as I'm concerned, the
> fewer people who have to split capture files into pieces in order to
> read them in Wireshark, the better.
>
> (And that code is, as far as I'm concerned, a display routine.)
That makes sense. Then we would just need to implement MVC code for
basic interfaces such as curses (and presumably people wouldn't be
loading huge capture files in that interface anyway).