SMN v6.0 High Level Design
In SMN v6.0 the entire interface is implemented as an SMN model, and it can also operate on SMN models so it can edit and operate on itself.
The Seed consists of an engine and a set of models.
Models is a data structure containing SMN system models. These models are structured systems of primitive elements, which are either data structures or functions. The functions are formed into a list of function definitions and are refferenced by integer routine_id's from within the model. Two examples of primitive elements are, a data element that represents 'position' for a system and a functional element that allows a system to display text or images on the screen that represents the observable state of the system. These are only two examples, but as the many elements of data and functions are woven together by SMN these form into higher level systems with coherent behaviours that can be used as 'programs' such as an SMN interface. See these SMN related discussions for more information on how this is achieved. In particular, the algorithmic structure of Models is discussed in relation to the mathematics of SMN and Finite Discrete Information Systems.
Engine is an SCSPL processor with an input pipeline that can process FDS's from multiple models (an SCSPL is a self-configuring self-processing language and an FDS is a function definition statement which is a 'sentence' of SCSPL and can be easily extracted from the system matrix within the SMN model. See SMN and SCSPL for more information).
The Engine and Models are all that are explicitly instantiated in the code and everything else arises from the operation of the engine on the model. Thus the engine and model are self-existent from an empirical perspective. For more information regarding metaphysical interpretations see the discussions regarding the metaphysical context within which SMN is situated, in particular the computational paradigm which describes the metaphysical foundation of SMN. Also see the discussion on the correspondences between SMN and other metaphysical paradigms.
Above is a schematic of the core of the engine, the central algorithmic 'hub' of the engine. Here is a link to the accompanying key and description.
The interface model is the first to be simulated by the engine and it implements the interface into the simulation space in which one can run other simulation models. One can edit the simulation models using the interface and one can also run an instance of an interface model within the simulation container as a way of developing and testing a new interface whilst still using the old one.
The rest of the SMN systems shown above are created in the sense that they arise from the operation of the engine on the interface model thus they are empirical systems with regards to the level of the engine. But they are not yet a part of the simulation proper thus they are still transcendent systems with regards to a perspective embedded within the simulation universe. These manifest the interface that provides the interactive view into the simulation space.
Then there are the simulation models (simulation universes) that one may load, save, edit, analyse or run. One can run virtual reality simulations or run programs or navigate multi-media spaces. Or generally interact with empirical contexts or experiential spaces of all kinds.
The program as a whole is essentially a high level operating system for SMN systems which are metaphysically coherent complex dynamical systems. An SMN program is a seed without the interface model, it just has a program model that the engine operates on. They are seeds that when planted in a computational space give rise to virtual systems.
Any program elements such as menus, buttons, view windows etc are implemented as SMN systems who's observable state results in the display of these objects on the screen. Thus all that the program requires is a basic operating system window with graphics functionality and the ability to make system calls. These are then used to program the primitive functional elements such as the ability to display an image on the screen or to write to a file. These functional elements are then woven together by SMN into complex high level systems thus the program as a whole is implemented in SMN.
Simulate is a control overlay for the engine, it can pause the simulation or step it forward by some number of steps and so on. It doesn't stop the engine, otherwise the interface itself would stop, Simulate just controls whether simulation related information is being processed by the engine.
State consists of two types of data, either program variables such as the current magnification level or boolean modal variables such as being in draw_mode or not. For example, if draw_mode = 1 (true) then the function clear_screen() is used only at the users command, and other actions are taken to preserve the image. If draw_mode = 0 (false) then we are in simulation mode so the background is empty space and should be kept clean of any image traces (this is handled by Display). Another example of a state is to accumulate statistics as the simulation proceeds so that other systems or the user can use this information.
These states provide a common information space that the user interacts with via the menus or hotkeys, then other program elements adjust their behaviour depending on this information.
Below is a diagram illustrating the menu system by which the user interacts with the simulator and the simulation. It currently just depicts the menus for ParticleDraw which is an implementation of a particle simulator that has been developed into an artistic drawing program. A more general menu schema will develop over time.
The interface provides either a transcedent (blue) or empirical (green) interface (it was previously a hybrid of both and not quite either). The transcendent view is the design view of the model's causal structure, whilst the empirical view is the simulation view of the model's behaviour. Through these two interfaces the user may interact with all levels of the virtual reality, both the transcendent causal level and the empirical behavioural or experiential level.
Hotkeys recognises user keyboard input and either changes program state (e.g. pressing 'p' to pause the simulation) or brings up a menu (e.g. pressing 'm' to get the Model menu from which one may load, save or edit a model).
Interact mediates user interaction with the model via the mouse, i.e. when one grasps and drags a particle with the mouse this is editing the model via the sub system Interact.
In each moment of a simulation all of the states that require updating are processed using their corresponding FDS's, then any cReps are processed. cReps implement the external appearance of systems, i.e. they represent them externally. They can write to the screen however they do so by using Display which generates the screen depending on various program states (e.g. magnification).
Image is the result of whatever is written to the screen. It can be built up as a drawing and then saved to file or more generally it can be used to capture any graphical state of the program.
File allows SMN systems to read from or write to files.
The following are brief runs through the interaction pathways to intimate how the various systems interact.
The Engine is started with Models as input and it instantiates the Interface Model which gives rise to the various systems that comprise the interface. Simulate provides a control overlay over the Engine, State represents all kinds of program states that control the programs properties, Menus gives the user access to these States and also to the Models, Hotkeys gives the user Keyboard access to States and Menus, Interact gives the user Mouse access to the Models, which is represented via Display, which constructs and manages the Screen, then Image is the result which can be saved if one wishes via File.
In one example scenario one might press 'p' on the Keyboard to activate Hotkeys which modifies the State so Simulate stops the simulation then one presses 'm' on the Keyboard and Hotkeys activates Menus and one loads new program Models from File. Then one presses 'p' again and the Engine starts processing the updated Models, which one can Interact with via the Mouse.
I can imagine SMN developed as a desktop environment, such as the Windows GUI, or Gnome or KDE in Linux but cross-platform, perhaps as an extension of Java. It would provide a graphical skin that mediates access to the underlying operating system. It would seamlessly integrate concept map technologies and a system theoretic metaphysics where every object in the environment would not only be a window or an icon, it could potentially be any kind of complex dynamical system. Ones desktop might be a 3D interactive environment populated by various interacting objects with complex behaviours. Or it might be an abstract multi-dimensional space populated with abstract objects that relate in ways and provide access to the computer and the programs. These various 'skins' could be highly flexible and easily customisable and programmable. The systems could be SMN systems or any form of software. SMN would provide a rich, graphical, programmable, flexible, intuitive, control system / interface between the user and the operating system. One could program it to conduct all manner of tasks and to respond in any way that you wish thus providing an intricately customisable user interface.
Is anyone in the Linux developers community or any other OS group or general developers interested in discussing this further? Get in touch... SMN provides a metaphysically coherent and mathematically derived event processing system that can coordinate information logistics of virtually any nature. Its numerous variants would have many applications within the field of operating systems. This technology is free to use and I will assist you in any way I can, including on-going collaboration of some kind. It would be interesting to develop a cross-platform interactive environment of that kind but OS's are outside of my area of expertise at present. Although I said that about windows programming not long ago and it took me only three days to learn that and to port ParticleDraw from DOS to windows.
I will add more details as they are ready...