Future plans for Inguma development

All right.  After the revelations two days ago about Inguma visiting us from the grave, the next thing is to make a bucket list of what needs to be done.  In a somewhat-ordered list of most to least important, this is what I'd like to accomplish:

1. Port Inguma to GTK+3 + GObject:
• Inguma is written in PyGTK + GTK+2, which has ceased development several years ago.  GObject is the new introspection from the GTK+ project which allows to allow the usage of language bindings for any library using it without having to rewrite things when the library changes.
• This should help us keep an easier install procedure for MacOS and Windows.
2. Port Inguma code to Python 3:
• While we were not looking, the world has finally moved to Python 3 and things like xdot.py are actually now GTK+3 and Python 3.  This is dependent on third-party code living in the tree or external dependencies that are only in Python 2.
3. Remove years-old cruft from the tree:
• Inguma has accumulated a fair amount of old code (pyew, krash, fuzz, scapy, pyshellcodelib, etc.) that it's either plain old and outdated or that has been getting updates in all this time.  Spring cleaning it is!
4. Remove Bokken from Inguma:
• Sadly, Bokken is not usable now with radare having evolved on its own for a few years now.  We will need to revisit that at a later stage.
5. Hide funtionality until it's battle-tested:
• In the open source world, there's always a debate about whether you should release early and often with incomplete functionality, or shipping only features that work well in a variety of environments and that are not going to crush those testers with very high hopes.
• Given that our development time is limited, I prefer to stay with a product that shows only stable features, and instead of removing lots of code that could potentially need to be added later, for now just hide everything else behind a config or runtime flag so we don't confuse new users with broken stuff everywhere.
6. Make documentation great again:
• We lost the wiki, but even if I'm able to recover it, I'm not sure if a wiki is the best way of keeping documentation updated.  I'm thinking about generating it automatically for specific versions so it's easier to change and upload.
7. Make modules...modular:
• The list of actions that you can make with a graph is very limited and hardcoded in lib/ui/target_dialog.py and lib/ui/graphMenu.py (if I'm not mistaken).  In order to make Inguma a proper open-source intelligence client, the list of transforms (borrowing a term from Maltego) has to be extensible and modular, and move away from the actual node-as-IP paradigm.
8. Ignore (or delete) the text-only Inguma client:
• For those of you who don't know it, Inguma started as a text-only application until Hugo built the UI in PyGTK.  Having to maintain both is beyond my expectations at this moment, so if you use it and it goes and eats your grandmother, don't come whining.  Take this as my one and only warning.
9. Fix the terminals code:
• It's broken (or it will be) when anything of the above happens.  It was already brittle and it doesn't like to be disturbed, but it's not a priority to really fix it.

All the above said, I would like to release a couple of versions in technology-preview mode just to make sure that anyone who wants to test it has a good starting point.