Updates on Steemportal

I have been quite waylaid recently with the return of my laptop and finding the best way to make use of its facilities. I now have a full time, hourly updated mirror of my home directory, where everything lives, including the APT .deb package cache, which on both machines lives in the much larger home directory, and is, along with my entire home directory, cached to the laptop's storage, updated every hour.

For future I have the ability also now to run servers on the laptop, such as a witness node, a headless bitmessage, and the like, which are now all elements of a total package that I am building up towards. I will eventually be making a big set of modifications to bitmessage to create a low latency, short message chat system, with something like 2-5 second latency being a reasonable target for usability. By the time I get to building this part into the application, however, probably Steem will have the new groups system added as well. So I guess @xeroc is gonna be busy implementing that when the new API calls are added to the witness node's RPC interface. And me too, adapting the short and long message system to it.

After some thought I figured the best way to propagate name/BM/IM address correspondences, is through a bitmessage subscription address, which my code will periodically send out current info, with a signature from the Steem key. This will make it very easy to find other users and message them, though of course, if such contact is unwanted, the client will have a blacklist it can check for which users' messages it will drop.

I have not made a huge chunk of progress with the coding, but now each object has local references to the core, SPinterface and SPconfig class instances created by the initial main module, which handles setting which backends and frontends will be used (I haven't yet added the by-name checks, I will add them but I am not sure that Git preserves whether files are hard or softlinks. I will try softlinks I guess, hopefully that works and then there can be steemportal-gtk steemportal-qt steemportal-wx and steemportal-web, each one automatically selecting the interface module correctly by default. I will complete this next, since I thought of it just now.

Please, if you want to test and help with development, write interface code, etc, don't ask permission, just adopt the project, make your changes, and submit them for inclusion, and I will merge them as soon as I see they are there. The project lives here: https://github.com/l0k1-smirenski/steemportal

edit
I have just done some digging and was pleased to discover there appears to be no onerous restriction on the size of strings in the dconf database, so I will be using a key to store a url history list and slicing and dicing with python's wonderful string slicing toolkit, and it will be instantly persisted. I also had in mind a configuration key with a fairly big string in it describing the current state of the GUI, so when it reopens, it precisely opens where it last was. I must not forget I intend to put the ability to have multiple tabs, this complicates the history data structure a little, but it's still just things like 'new tab: URL, adjustment' logged, and as the string gets too long, it trims the tail.

Gnome interfaces try to achieve the ultimate goals of the original Smalltalk system that kicked off modern object oriented programming and graphical interfaces. Everything is persistent, you switch off, then back on, and it comes back as though nothing happened, and you can even walk back in the history. I have ideas about making this a central control mechanism in an operating system, enabling all reversable operations to be reversed. Log filesystems and the like. I suppose I am learning how to write a simple log filesystem.

edit 2:

I am not exactly going hard with this coding project. Every day I do some little things to it, now I think I have got most of the general structure sketched out and I can start working on some concrete things. I need to still write a specification for URL log data strings, as well as GUI configuration strings, and parsers that slice it up and give you what you are looking for, modify it as per request (such as adding a log cursor movement to the URL log to show where the 'current' position is and meaning you can track forward from it. A more advanced log view would allow you to see your URL log as a tree. The GUI interface also stores the latest state of which URLs are open in which tabs. I am aiming at something that resembles a web browser, in most respects.

I have ideas that come further along the track, as designs for advertising posts, including inventory management, reviews and such. I want to eliminate the necessity for a million different interfaces and create a simple one that can be run natively, that allows for enabling market activity within the Steem system. So it's a bit like a category system for web pages. Standard post-and-comment posts are one type, the original primary type. But then this could extend to have posts that market an item, give a price and sales structure (If someone wants to make auctions - well, that could be added as a feature too). Then you have a different type of category of Steem page - an advertisment, which has a special class of comments called 'reviews' posted by those who have a registered transaction on an item, along with the general comment feed.

Edit 3

I had a rather difficult time wrapping my head around how namespaces work in Python when you import source files. Turns out each source file creates a namespace. This caused an indirection in code I was running to use, in the gtk3 interface module, that was calling, well, I don't know what, but the program froze, and had to be stopped and killall used to get rid of its floating zombie process. Turned out the solution was to initialise the objects at the end of the modules, which could then be referenced with modulename.objectname. And after about two hours tearing my hear out, finally, up pops a little window, that I can close and the process ends.

So I am now working on the interface, and the data format for storing its state so when the user changes it, the state is stored, and this state can be reloaded upon next launch. (At the option of the user's configuration, of course). Which brings up an additional dconf entry that the schema needs...