🚀 go-pugleaf

Followups re-directed to c.s.a.tech

Document Editors
----------------

A Common Control Interface
--------------------------

Contents
--------
�  The Problem 
�  The Purpose 
�  Abstract description 
�  Implimentation decsription 
�  What I'd like from you 
�  Possible future uses 
�  Notes 

This document has been posted to comp.sys.acorn.* groups as a request
for comments, if you wish to send any comments directly to me or
require the newest version of this document mail me with your request. 
mailto:ObjEd@bigblue.demon.co.uk 

The Problem
-----------
This description of the problem is overly biased towards the solution as I
see it.

The Acorn market has many applications which duplicate jobs such as data
bases, drawing packages and  report writing. Many of these contain inovative
and useful code (otherwise they would not be used) but they  can't do
everything. Many have proprietry data formats that make the interchange of
data difficult to  acomplish.

Many software houses have seen the need for modular applications that can
change with the times and be  expanded without the need to re-release the
whole package. These often come in the form of a proprietry  interface to
their application so again inovative code cannot be reused with out more
work.

There are dynamic linking systems that allow parts of applications to be
updated and loaded at run time, but  an application can only use those
modules that it was coded to use. The applications interface is too rigid to 
allow any expansion of it's functionality.

There are protocols to call other applications and get them to do some work.
These are limited by the fact  that they do not share the same data, the
caller may have to pass data to the other application and then the  callee
pass the result back.

The functionality that existing code libraries provide is limited. Libraries
still need to be developed for some  types application. And need I say more
than some people think that the existing libraries need re-writing just  to
get them right.

Solutions to some of these problems have been proposed more frequently in
the past year or so. Acorn have  provided us with the system of modules, but
it requires knowledge of each individual swi to be useful. 

The Purpose
-----------
1.  Improve functionality of applications in general. 
2.  promote the interchange of common data types between applications. 
3.  Increase the application base for Acorn machines. 
4.  Increase productivity of application writers by reducing the amount of
    duplicated code.
5.  Provide a freely distributable specification for this
    architecture.
6.  Set a minimum standard of freely available control objects so everyone
    can use all standard data  types even if they can't edit them.

Source code need not be available for any objects and need not be freeware.
My hopes are that comercial  software houses will take an active role in
this specification and also in the development of applications and  objects.
Only the interface needs to be made available if it provides extra
functionality. 

Abstract description 
--------------------
The application does not need to know what it is editing only how to access the control objects which will 
do the editing for it.

A document needs to be held in memory where all the control objects and the
application can access it. each  data type needs to provide information that
can map it onto a display such as height, width, position in  document,
layer etc. The way in which the data is layed out in memory should allow
both the application  and control objects that form composite data types to
manipulate the data.

The application should be split up into 3 parts the application which is
linked with an object manager  library, and two layers of control objects.
The manipulator objects and editor objects.

Editor Objects provide basic editing functions such as select, unselect,
copy, cut, paste, render, print, create,  rotate, compare, insert new
value(s), alter contents etc. some may not have any meaning in the context
of a  specific data type that the editor object controls. Also needed is a
mechanism whereby an object can be  dragged and special drags while selected
will update the data and state information correctly.

Editor objects need to provide information on what services they provide,
and also perhaps a unique  identifier for the data type they edit. and
perhaps a method of warning the application when the data they  have edited
needs re-rendering. It's not so simple as the editor re-rendering itself if
it's size has just been  altered, as it may have to affected other objects
for example.

Manipulator objects provide extra functions such as search, sort, convert,
encript, decript, undo, redo etc etc  etc. as you can see these do not
normally need to know what they are dealing with and so often have  meaning
to more than one particular data type.

Manipulator objects require some way of agreeing on an interface with the
host application which then  needs to link those services that the
manipulator provides into a menu or attach a dialogue box. 

Implimentation decsription 
--------------------------

Storage on Disc
---------------
Storing data types in a heirarchical directory format similar to that used
in RAM would allow atomic types  such as draw, sprite and text to be held in
individual files and allow editing of such data by existing  programs. I
would like an image file format to be used in the future but that is more
work than I think I can handle right now.

By allowing objcts to save themselves (if they allocate their own memory)
then documents can be saved in a similar format as they are held in RAM and
the application no longer needs to know how they are organised.

Storage in RAM
--------------
A herieracical data structure (in the form of a tree) could store each data
type and allow both application and  control objects to access all the data.
A possible implimentation could be using draw files to store new  objects
in. would this impose too much of an overhead? Using this method gives a
structure to the objects,  maps the atomic types well and suits the needs of
the rendering data common to all objects.

An alternative to this would be that objects look after store themselves
either by a dynamically linked  memory manager object which it is up to the
user to configure, or built into the object when it was written.  this last
option would not make this system very useful. Using a memory manager
selected by the user  would make writing the front end application easier
but would impose the requirement that all objects use  anchored pointers
with the expectation that a shifting heap manager is used.

Object Manager Library
----------------------
This is an object library that is linked to the application and provides the
interface to the object manager  module. This needs to provide an extension
interface for object editors known to application when they  provide
functionality outisde that of the common control interface.

Call interface
--------------
Something of the form call(object, action, arg1, arg2,...). This interface
would be provided by the object  library so could be changed for different
languages, even BASIC.

Object Manager Module
---------------------
This would work something like the Shared C library with dynamically linked
functions. It would provide  the interface with the applications object
manager library and the dynamically linked objects. This will  allow newer
interaction methods to be incorpertated without making either the statically
linked manager  library in the application or the dynamically linked objects
obsolete.

Common data requirements for rendering of objects
-------------------------------------------------
what information needs to be held on all renderable objects such as size
shape position etc. Shape extension to be defined later? 

Error Handling
--------------
I would like to be able to impliment a system of error handling whereby the
method used to return errors is  decided by the aplication. There are
several methods I would like to see. A global error handler function,  C++
exceptions, the C equivalent of exceptions namely (setjump/longjump buffer),
and the classic method  of returning an error flag with it's associted
convoluted error correction code.

Interface agreement protocol
----------------------------
should control objects provide enumerated options so editors can make up a
tool bar from unique options  names (common names to identical functions eg
ALIGN centre etc)

Low level interacton methods
----------------------------
EG should objects attach filters for drag operations to the application or
should application supply the drag  operations to control objects.

The following text is just my notes and will be expanded upon at a later date. 

App Lib:
  SWI Link and initialise Object manager to this app
  Activate_Object(Action,Obj_ptr.....)

Manip Obj:
  Search
  Sort
  Encript
  Decript
  Undo
  Redo
  Storage eg Array,List,Tree,Graph,Table (a la spreadsheet)
  Convert
  Quantize
    [ Smooth, dither and other graphics manipulations ]

    functions
      Get Dialogue Box (enumerated dbox......)
         [ enum'd dbox would be returned by another function ]
      Get Menu List (Section Type....)
         [ eg Selection, Save, Edit, Display, Mode etc ]
      OTHER INTERFACE METHODS
         [ by using common names for actions, and macro icons eg sliders 
           etc the appliacation can build dialogue boxes to it's own syle. ]

Edit Obj:
  functions:
    Render
    Print
    Select
    UnSelect
    Copy
    Cut
    Paste
    Delete
    CreateNew
    Insert(Atomic_Type..)
    Rotate
    Compare

  Attach Wimp Message/Event Handlers
  Detach them
  List implimented functions

Data Types
  Atomic Types
    Text
    Integer Number
    Float Number (double or float?)
    Sprite
    DrawFile

  Attributes
    Xpos
    Ypos
    Xsize
    Ysize
    Level
    Rotation

What I'd like from you 
----------------------
I'd like your suggestions as to how this could be implimented.

I would like any C++ gurus out there to comment on the interface and how
well it could be mapped into c++  classes. Most importatnly I would like
your comments on error handling. If a global error handler is used in  C and
either a setjump/longjump or if a direct call to a global error handler is
used should exceptions be  used in C++. should an internal error handler be
used and mapped onto the programers choice of handler.

security: preventing virus attacks (rogue control objects) from being
incorperated into applications. perhaps  a magic cookie placed in each
control object and limiting them only to those configured by some 
management software which the user controls, this could also be used to
manage memory usage more  efficiently.

Possible future uses
--------------------
By reworking the interface code it should be possible to get it working on
multiple processors. This would  depend on the memory sharing abilities of
the multi-processor card.

Notes
-----
The interface need not be very efficient since the function called will be
doing the bulk of the processing. It  would be nice to have an efficient
call interface though. 

This document is a request for comments, if you wish to send any queries to
me then mail me. ObjEd@bigblue.demon.co.uk

For the latest version of this document in html check
http://www.csc.liv.ac.uk/users/u1smt/ObjEd.html

Simon
-- 
mailto:simon@bigblue.demon.co.uk
mailto:u1smt@csc.liv.ac.uk
http://www.csc.liv.ac.uk/users/u1smt/u1smt.html
... A pound of puppies; a college of cardinals; a bowl of weevils