frontends: add GTK frontend

[FFY00]

I understand that yet another frontend might be undesirable from a maintenance POV but I think it is very relevant. Depending on your desktop environment or setup, Qt might feel out of touch. There are some drawback from the lack of system-wide configuration, for eg. I have a HiDpi display and Qt honestly does kind of a bad job dealing with it, it also completely breaks the look and feel of my applications but :man_shrugging:. I find GTK quite easy to work with, all things considered, and I do not think it would be that much of a maintenance burden. With that said, I would available to maintain this frontend if you want, I don't want to put extra burden on you :blush:.

Right now only the data streaming is implemented, the packet details and hex view are missing. You can merge as is or wait until I add the missing components.

[FFY00]

Okay, I think it's finished :grin:

[FFY00]

@Qyriad friendly ping :slightly_smiling_face:

[Qyriad]

Thank you for the poke. And, this looks pretty awesome; thank you! I have 0 knowledge of GTK programming, so I doubt this will be maintained by me, meaning that officially this will be Unsupported, but I'm not against having it in the repo.

That being said, I haven't used a high DPI display in a while, but I thought Qt did actually have reasonable DPI/scaling options/handling, just with environment variables, which if I recall correctly is how you do that with GTK too. I don't think that's a reason to not merge this, but I'm curious what your DPI issues are, since I thought Qt5 handled that well—well, at least about as well as DPI handling gets on Linux—and I'd like to know if I should open an issue for it and look into possible ways to get the Qt UI to handle it better.

I also personally haven't really noticed ViewSB feeling particularly out of place style-wise, even though I use a GTK-centric environment (Gnome)—or at least not any more out of place than most modern applications like Chromium, Firefox, Telegram, et cetera, or even my terminal emulator (Alacritty).

Anyways, back to this particular PR. In my preliminary testing, I found that this UI crashed no matter what backend I used, albeit with different error messages. For example, running it with the usbmon backend and then plugging in a new device crashes with:

Process GtkFrontend process:
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/home/qyriad/code/gsg/viewsb/viewsb/ipc.py", line 92, in _subordinate_process_entry
    task.run()
  File "/home/qyriad/code/gsg/viewsb/viewsb/frontends/gtk/__init__.py", line 158, in run
    self.handle_communications()
  File "/home/qyriad/code/gsg/viewsb/viewsb/frontend.py", line 225, in handle_communications
    self.handle_incoming_packet(packet)
  File "/home/qyriad/code/gsg/viewsb/viewsb/frontends/gtk/__init__.py", line 146, in handle_incoming_packet
    len(packet.data),
TypeError: object of type 'NoneType' has no len()

If you look at the Qt frontend in _create_item_for_packet(), I have length = len(viewsb_packet.data) if viewsb_packet.data is not None else '' precisely to solve this problem, since dataless ViewSBPackets (which can represent e.g. dataless transactions or Setup Transfers without a data stage) exist. And there is a difference between a length of 0 and No Length.

I'm curious what backend you tested this on, since that might help me figure out what additions need to be made to handle the quirks of other backends. Unfortunately, such quirks are a natural consequence, since different backends are capable of producing different levels of detail of analysis.

The other thing is that, unless I'm mistaken, this doesn't show the subordinate packets (the transactions that make up a transfer, and the packets that make up those transactions), which I think is one of the more useful things a USB analyzer should offer, since the nested structure of USB requests/transfers/transactions/packets is one of the more unclear aspects of USB, since e.g. libusb doesn't go any further down than the transfer level.

[FFY00]

Sorry for the delay! I probably messed it up when commiting.

I think I am going to close this for now. I would definitely like to have an alternative graphical backend to Qt but I feel like we could probably do a bit better than GTK. I will assess and figure out what I think might be better.