GUI / Widget Based Bulletin Board Software Protocol

Tue, September 04 2018

GUI / Widget Based Bulletin Board Software Protocol


Some could argue that Bulletin Boards were the gateway to the successful adoption of the Internet in the United States. If you look at how many other similar solutions were being offered in different countries as an evolution to the standard telephone. There were video phones, education networks, you would leave voice mail without the recipient having an answering machine. None of these solutions survived when BBS users started demanding local BBS systems provide access to features/services on the Internet. Many BBS operators (SysOps) were forced to evolve from "Internet Gateway" conduits, to actual dial-up SLIP/PPP Internet Service Providers (The path I took).

During the BBS era, a form of network existed using packet mail concepts... called Fidonet. With the invention of Fidonet and a decade later the growth of Fido and all of the sister networks - it was amazing to see how many people just wanted to run a BBS in their house. Fidonet itself peaked with around 39,000 BBS systems connected around the world and now, it struggles to keep systems going with about 1,400 world wide. I operate two different systems, one on Modem 56k Dial-Up, and the other in a Rack of Servers in Arizona. I have been running a script based BBS system so I can make changes on the fly while users are connected. However, in today's era where sockets allow thousands of users concurrently, the old BBS functionality does not fit. Then add in the fact Microsoft dropped NTVDM support, which is how windows could still run old DOS programs.

Since January 2017, I have been scratching my head - with the socket suite I built in 1995 that surpasses he performance of any other socket suite I have tried over the decades... I want to have more than a service running out in the Cloud. As a software developer, I tinker constantly - and while experiementing with a GUI component that is a "Document" manager - I accidently designed a 4 node BBS. I ported some of QuickBBS 2.8 source to run in this 4 node view - and I was amazed how much it felt like being a SysOp again.

Of course being able to see hundreds of users concurrently is impossible to render. However in the mid-90's there were many attempts to change the presentation aspects of a BBS - going graphical on the client end, while keeping the BBS software text based. NAPLPS, later RIPScript, then WIP; are some of the attempts to introduce a graphics client interface - then came along Hotline for the Mac and eventually Windows. It kept true to the BBS world, instead of going after the P2P file piracy systems like Napster, Gnutella, Limeware and Kazaa. Which brings us to my revised "Widget" oriented protocol.

* NOTE: I am not inventing anything here - this is actually how most RAD Development frameworks work. Instead, I am simply documenting how to implement this protocol in other solutions - like BBS or in my 1998 solution called DXMotherboard with DXChips ~ where we were serializing Widgets and Code to make true Client/Server applications. In this document, I have switched the design to use JSONRPC for its ease and small footprint.


Instead of a vector based drawing protocol like NAPLPS, RIPScript and even SVG. Why not look at the individual components aka Widgets for the GUI grameworks. And keep the "Palette" of Widgets focused to (a) a common set available almost everywhere, (b) applicable to what a BBS is and does, and (c) even possible to port most if not all BBS games.


In our palette, we focus on Window (the form for which all screen painting is being done) as the base for each use interface - be it interactive of a notification. You can have one or more Window Widgets visible, however, in most operating systems and frameworks, only one Window can be 'focused' at a time. Of course, in the BBS days we had "screens" - and then there were those amazing ANSI screens the hacker/art groups made. To keep true to this capability, a Window can have a color background, tiled image background, or a full graphical rendering backage.

Lasly, a Windows is required for all other Widgets to display. You cannot add a widget without having a parent and the base parent is usually a Window.

Children Layout

Everything placed on a Window widget can either be places at a fixed x/y position (in pixels from the top left of the "Client Area" of a Window (e.g. just below the title bar)), or can be aligned to top, left, bottom. or right or the whole client area.

Children Layers

Everything can be places on-top of other widgets - producing vivid layouts for screen. This in a 3D oriented description is the Z-Index, where Layout uses the X-Index and Y-Index for left to right, and top to bottom placement. The Z-Index is the 3rd Dimension for height/depth of a widget in a stack of Widgets. One mistake someone may make is load an Widget and except setting the Z-Index higher (closer to the front) will bring it to the front, please avoid this mistake as some frameworks do not support this. If a widget needs to be closer to the front, make sure it is loaded later in the "stack" of things to display. Or for a gray global shadow, you can load it, but set visible to false... then set visible to true when you need to gray out everything below it. (This is a common way to force a screen to render modal windows - like an HTML framework for example).


A Panel is a container,


Place text on screen, you control x-Index and y-Index, text, color, size and optional style of bold or italic.


Input box, you control the x-Index, y-Index, width, variable name, color, background.


Password input box, you control the x-Index, y-Index, width, variable name, color, background.


Dropdown input box, you control the x-Index, y-Index, width, variable name, color, background, choices.


Popup input box, you control the x-Index, y-Index, width, variable name, color, background, value.


List choice box, you control the x-Index, y-Index, width, height, variable name, color, background, choices, selected.


Multi-line Text Area input box, you control the x-Index, y-Index, width, height, variable name, color, background, content.


Multi-line RichText input box, you control the x-Index, y-Index, width, height, variable name, color, background, content.


Checkbox, you control the x-Index, y-Index, text, variable name, color, background.


Radiobutton, you control the x-Index, y-Index, text, variable name, group ID, color, background.


Statusbar, you control the x-Index, y-Index, simple text, variable name, color, background, array of panels.


Button, you control the x-Index, y-Index, text, event. (See below list of common events, and framework events).


Panel with 4 common buttons, you control the x-Index, y-Index, Array[4] button text, Array[4] button event.


Event Driver Widgets


A simple event timer, you control how long to wait until event first (like HTML SetInterval) and event.


A simple event timer, you control the delay between enable and disable visible, and the wdiget.