steemportal app framework for selectable interface frontends - stubs now completed

I have built the module import framework so that now interested parties can work work on distinct interface frontend modules for steemportal. Again, the git repo can be found here:

https://github.com/l0k1-smirenski/steemportal

I have only built the framework and placed stubs for each frontend interface module. I will be working on the gtk3 unit first, and in it I will design the structure of the classes and calls that the core will use, essentially a namespace at this point, for which each module will have a common class/function naming scheme. I have also added a stub for a web framework.

The objective of doing this is so that everyone working from python 3 and the piston library can eliminate duplication of labor. I can continue to work on my specialised area, and others can work with me on the core and namespace for the interface as well. I will start writing up the API spec as I develop the gtk3 interface module, which can be used by the developers of other frontends so they know how to set up the base interface class and call modules.

Modular configuration backend

I have now also added modularity for the configuration backend system. I am only going to create one for dconf, but others can make .ini, or flat file, or whatever other relevant backend is required, the argument list will need to be added to the argparse to allow a user to see the available options, but it defaults to the ones I am implementing. Using argparse, it will also be possible to make softlinks or renamed copies of the main.py that automatically sets the interface by a name, for example steemportal-gtk could automatically select gtk3 and dconf, and steemportal-mac could automatically use carbon and whatever MacOS's config system is, and for steemportal-win32, it could automatically set the parameters as win32 gui and winregistry or .ini.

The gtk3/dconf combination will be fully event-driven, any configuration changes will trigger update events for any object that uses this information to set its behaviour. So, for example, if you are in the blocklist edit dialog, and unblock someone, and their post is on a display object currently open, it will instantly undisappear their posts and comments in the feed. This is one of the reasons I like the Gtk/GLib system so much. There is nothing stopping this kind of feature being added through the python primitives to do it, but with the GNU gui system, this is all already easy to implement and runs largely with native code.

WOW!

Ok, people. So you are all egging me on, and now, I think I have figured out what I am doing next.

I will create the interface and configuration API namespaces, functions, and rough descriptions of what each part does. I will also, as part of this, create the function namespace for the 'core' function. @xeroc has told me that he already has part of the codebase for a python/qt interface done, he is working on the web interface with piston.web, @leprechaun has told me he wants to work with python/wxwidgets. That leaves me as architect and gtk3/glib2 specialist.

Well, it's all very unfamiliar to me, but I know that I can do this, so I will do it. I think a unified, python/piston based app interface for desktop pc's won't be very long in the coming, if there is anyone else reading this who thinks they can contribute, it certainly won't hurt. Especially Qt and web interface specialists. I think I got gtk covered.

Update

Yes, I have started working on sketching the applications' namespace out. I will continue tomorrow. I am going to force myself to stay on this level of abstraction until I can't think of anything more that needs putting in.