Wireshark mailing list archives
Re: The possibility of a curses based Wireshark
From: Stephen Fisher <sfisher () SDF ORG>
Date: Fri, 28 Nov 2014 13:06:44 -0700
On Fri, Nov 28, 2014 at 11:43:36AM -0800, Guy Harris wrote:
On Nov 28, 2014, at 11:23 AM, Stephen Fisher <sfisher () SDF ORG> 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). ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- The possibility of a curses based Wireshark Stephen Fisher (Nov 28)
- Re: The possibility of a curses based Wireshark Stephen Fisher (Nov 28)
- Re: The possibility of a curses based Wireshark Guy Harris (Nov 28)
- Re: The possibility of a curses based Wireshark Stephen Fisher (Nov 28)
- Re: The possibility of a curses based Wireshark Guy Harris (Nov 28)
- Re: The possibility of a curses based Wireshark Guy Harris (Nov 28)
- Re: The possibility of a curses based Wireshark Stephen Fisher (Nov 28)
- Re: The possibility of a curses based Wireshark Guy Harris (Nov 28)
- Re: The possibility of a curses based Wireshark Stephen Fisher (Nov 28)
- Re: The possibility of a curses based Wireshark Bálint Réczey (Nov 29)
- Re: The possibility of a curses based Wireshark Edwin Groothuis (Nov 29)