Thoughts about what models we'll need

[Bruce Long]

Hello all,

As a quick demo solution we can write a "theme" that merely generates a list of commands to draw or modify an item.

But in the longer run we need something more flexible. I want to open a chat on this so that we don't have to redo much to get from demo to final.

Here are some thoughts, not necessarily organized or complete.

Tags that describe things should describe their shape/color or content but should not say anything about how they are streamed(1d) drawn (2D) or rendered (3D).

For example, we could define rectangle, oval, square, circle, rounded-rectangle, etc.
The descriptions of these don't have to follow a set pattern and we can give more detail as needed.

• We could refrain from defining them and just include fields for size, diameter, etc. Then we would need drawing/rendering code that knew how to draw these shapes. (we already have this of course)
  
  
• We could define them mathematically somehow (e.g., assume a plane of points, which points are 'in' the circle, rectangle, etc.)
• Then we could give the engine a choice of whether to modify individual points, call a library, use the GPU, etc. (see below)
  
• The optimized engine can hopefully do 'dirty rectangle' analysis to avoid re-rendering things.
  
  
• Fonts are shapes too.
  
  
• Things that would not normally have a shape (e.g., a name or address or temperature) can be mapped to a text layout or a graph or chart or something.
  
  
• Once we have core shapes (circles, spheres, cones, fonts, lines, etc.) we can map more complex shapes/objects to them.
  
  
• We need to avoid tags like Draw_Circle and instead define stream, draw, render, and then, circle, square, etc.
  
  
• But we also need to be able to say draw using theme X on display Y using technology Z.
• So we also want to avoid Draw_using_gfx, Draw_using_openGL, etc.

I propose a tag called "command" that encapsulates the idea of doing something based on an action type and arguments.

Then we could refer to/use

• command, list of commands
• drawing command
• rendering command
• audio command
• gfx commands
• openGL commands
• framebuffer commands
• etc

we then query for a list of drawing+openGL commands that render theme X over myStuff.

Thoughts? Other ideas?

BL


--
Give me immortality or give me death!

[David Van Duzer]

Hey Bruce.

The Proteus learning curve is still a little bit steep, so I'm not
sure how much my opinion is worth here, but...

Can you help me understand how the "command" tag would be different
than the "eval" / "execute" tag?

--

If this is centered around "action type" and "arguments" then it's
fairly similar to principles behind HTTP / REST architecture. You've
got standard CRUD operations (loosely) with GET/POST/PUT/DELETE and a
handful of others. Then there's the target URL/resource for the
operation, along with the querystring for arguments.

--

On another note, it might be helpful to distinguish between
user-facing features, and developer-facing features. Is there a
separate "command" tag to encapsulate requests that are coming in from
a user input device?

Think: the user wants to do A, so the commands to execute are X, Y, Z.

versus

The user wants to do A, so the command is A' which translates to
functions X, Y, Z.

dvd