Design options for prototype

[Bruce Long]

Hello all,
I'd like to provide some more clarity on how the prototype draws
things. There are a number of options and we can start simple and add
features as we go.

First, there is the already existing "switch statement in a loop" that
takes an infon list of primitive drawing commands (circle, line,
rectangle, etc.) and 'draws' then. Currently, this uses SDL_Draw but
we are switching to SDL_gfx for transparency and other features.
Eventually we will add openGL, Cuda, etc.

Currently, the list of drawing command primitives is hand-coded in
display.pr. The next step is to change this so that it is generated
from myStuff, a theme, preferences, etc.

Let's look at a pseudo code, C-like example then think about how to
convert it to proteus. The following 'code' is supposed to produce the
stream of drawing primitives to be displayed.
--------------------
For each item in items-to-draw
Based on item's type, // and perhaps other things like size,
i.e., very large lists may display differently
EITHER
Find a C++ routine to do the drawing // e.g., circle,
line, text-in-a-font, etc.
OR
Find a pixel-map in Proteus that mathematically tells
whether pixels are in/out what color
Search these for the pixel-map:
preferences
User's Theme
The object itself // e.g., a circle should
know it's own pixel-map. (all pixel in a radius from the center)
In a library of maps for various things. //
Some of these could be generic visualization methods, others could be
maps to those visualizations. Addresses, generic 'structs', text-
files, hex-files.

--------------------

What are some options for doing this in Proteus?

1) The above code could be written in C++ in slip.cpp just about like
it is. But if we did it that way we would loose the flexibility of
having the engine try different thing, optimize processes, etc.

On the other hand we could mix and match the following:

2) Put the "for each" loop in Proteus. Eventually this makes sense as
it will allow the engine to farm the work out as needed.

3) Write a C++ function that will choose a way to translate item to a
list of drawing primitives.
3a) Call that function from slip.cpp
3b) Put the function into functions.h and 'call' it from Proteus
* The function could do low-level shapes in Proteus or C++
* It could use C++ or Proteus to search for pixel-maps

Ultimately, we want all of it to be written in Proteus as a command
like "Interact with user X via touchscreen Y using theme Z" But that's
a big step. Better to do a little at a time.

ASIDE: Why would we want all of it to be written in Proteus? Many
reasons some of which are:
* The engine will be able to optimize the process or farm it out
to a grid or GPU or threads.
* When the engine knows it is supposed to interact with "User X"
it will automatically use valid security measures to ensure it is
doing that correctly. If a new security flaw is discovered it will
take the form "that might not be user X if ____" That assertion alone
will make the engine use additional checks on your identity to form a
valid inference.
* What if we later have a new thing which isn't a touch screen? Or
if we want it do some something other than "interact"? E.g., maybe
there will be a theme that requires two touchscreen.
* We may want to change it to interact with User X or User X's
friends if they are currently holding the phone.

Coding it in Proteus and not C++ gives us that flexibility.

For now, we should code all or some of it C++ in slip.cpp. Let me know
if you are working on this and don't want to have a collision.

Bruce


P.S., The next topic might be switching from a hard-coded 'items-to-
draw' to a generated one.

[Davide Del Vento]

> For now, we should code all or some of it C++ in slip.cpp. Let me know
> if you are working on this and don't want to have a collision.

So far I've not been doing anything, too busy with the rest of my
life. I haven't even looked at the slip/slyp code yet, so feel free to
do your changes.

Bye,
Davide

[Bruce Long]

Hi All,
I have done a little more work on the design of this. Here is the
initial design I propose.

(Terminology) There are three possible ways to code each section:

Hard-code ==> create an infon by hand in a file or write C++ code and
call it from slip.cpp

Firm-code ==> create C++ code that will be placed into funcitons.h and
called from proteus code to create infons.

Model ==> write Proteus code


The goal of the code is to produce a stream of drawing commands (which
trigger calls to SDL_Draw, SDL_gfx, etc.). The drawing commands will
replace the display.pr file which is currently a hard-coded stream of
commands. In other words, we want to replace the hard-coded display.pr
with a model.

The model should take a myStuff and a theme as inputs.

We should be able to switch themes to demonstrate how a new UI or view
can be created. (This switch can be hard-coded for now; we can just
rename the files and re-run slip.)

The tasks are:

1. Hand-code myStuff.pr
- Later this can be calculated from a model
- It's a list like this: {item's type, view-type, item-to-display,
{position, orientation, scale}, preferences }

2. Write a firm-coded draw() function which
- Takes one of the infons from myStuff, (let's call this item-to-
draw)
- uses the item-type and view-type to select a Proteus function
from theme.pr // ask how
- packages the function with item-to-display and item-to-draw's
position, orientation, etc as arguments
- returns // the engine will then normalize the theme function and
process the new items to display.

3. Hand-code some themes

4. Create the loop infon that will keep calling draw for each item in
myStuff and send the results for execution. // This is done but not
tested.

5. Work with tags to make the above look recognizable to humans.


I have the skeleton for item 2 done.
Item 4 is done but may need tweaking.

Davide, could you do item 2? We could chat about templates for 1 and 3
but you would also do those because they would be our inputs.

David, would you be able to make it work with SDL_gfx?

I would do 5.

[Davide Del Vento]

> Davide, could you do item 2? We could chat about templates for 1 and 3
> but you would also do those because they would be our inputs.

I think so, but what's the timeframe? I haven't done much yet :-((

[David Van Duzer]

On Apr 16, 2011, at 12:10 PM, Bruce Long <qst...@gmail.com> wrote:

>
> David, would you be able to make it work with SDL_gfx?
>

I'd need some help, but I'd like to try.

[Bruce Long]

I've added loadInfon and draw as 'firm-coded' functions (see Functions.h). The draw function is just a skeleton currently.

using clip:  loadInfon:'FileToLoad.pr'   will load and normalize it. The infon should be enclosed in <%   %>. (see tmp.pr)

For even more fun try this with clip:

{2, 4, loadInfon:tmp.pr 11, 13}

---
Now as for draw:, the function should take an item-to-draw like this:

draw:{type, sub-type, item, {x,y, scale}, otherArgs}

We can make it do this for all the items-to-draw in a list like this:

// This is done with the current draw which just takes a number and adds one to it
Proteus: {draw:{2, 4, 8, 2, 10}|...}

Yeilds:  { | *1+3 *1+5 *1+9 *1+3 *1+11 }

You see, draw was called successively on each item and the results were made into a list.

So we can hardcode something like {draw:loadInfon:'itemsToDraw.pr' | ...} and feed the results of that to the slip drawing loop.

---
So, the next step for draw is to make it go into the list infon given it and pull out the items: string, string, infon*, list-as-positions, list-of-args. Perhaps pull out the positions and args too. Args could be left off for now; I don't have any examples where they are needed.

Once it pulls those out into C++ variables we can use them to generate the drawing command list for that item by finding and applying a theme item. (As I described in an earlier post)

If you make any progress or have comments, just post it here and I'll continue where you leave off.

Cheers!

Bruce