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. I've wanted such a feature so many times over the years when I'm logged into a remote box. That way I wouldn't have to capture packets and then transfer them to another machine for analysis (or do X forwarding).
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. It seems like we're going from being "married" to GTK to being "married" to Qt. I know there have been brief discussions over the years about supporting native Windows/OS X/etc, but that was deemed too much work to maintain the specifics as everyone would have to learn to code for every platform to fix bugs/make improvements. But is there a middle-ground where we can still use multi-platform GUI toolkits while still allowing for the possibility for another user interface such as curses? I would be willing to work on refactoring the code some more and this could help us support GTK longer (is that desirable?) as well as other user interfaces such as curses. It would also make it easier to move from Qt to another toolkit if the need ever arose (I'm sure we didn't expect to need to move past GTK years ago). 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. What does everyone think? ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe