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".
If it can't use file.c, that's something that should be fixed if possible.
> 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 statistics taps are one example, but the taps that construct tables of information and display them (e.g. the service response time taps) should probably be handled with common code to manage the "model" (the tables - plural, see, for example, the SMB SRT tap, which has a table indexed by SMB request code and, for some sets of "transaction" requests, tables indexed by transaction type), which arguably should be in the dissector itself, and display code for Qt Wireshark, GTK+ Wireshark, curses Wireshark, *and* TShark, to show the tables to the user. (The conversation and endpoint taps have already gone in that direction.)
> 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.)
