On Jan 6, 2012, at 6:15 AM, Roland Knall wrote:
> Ok, let me clarify the idea. Let's for instance say, that you want to
> have a graphical representation of the inner-workings of a
> communication of two machines. A scenario which comes up very often
> using industrial ethernet protocols. Than you want to integrate such a
> view into wireshark. Doing so requires a lot of changes all over the
> GUI code, and implements code which others won't need, bloating the
> overal gui interface. Other add-ons that come in mind here are all
> things under the "Telephony" menu or most of the "Statistics" menu.
>
> Now, if you could add gui plugins just on the base of dissectors
> loaded, that would enhance the usability for the tool, and on the
> other side would allow for a better development of such tools. Let's
> call them interface plugins.
Or let's call them "tap plugins", because that's what the plugins dialog box calls them.
(I.e., we already support them, although we don't ship any such plugins with Wireshark as samples.)
> Let's just add a plugin structure for generic interface
> plugins, and they should be able to register, that if a certain
> dissector is being used, they will be added to the menu structure.
See Anders Broman's comment.
> On another note. If in the long term Qt is the way to go, should all
> references to gtk usage be replaced by a more generic version of such
> functions, which in the meantime call the gtk version as a first step?
Well, if you mean QtCore and GLib rather than Qt and GTK+, that might be useful. It would either have a C API, sitting atop C++ APIs in the QtCore version, or a C++ API, sitting atop C APIs in the GLib version, or what might be some fairly satanic macros.
