Add LiveCode

[billhemsley]

Tool Name: LiveCode

Link to the tool website:

• https://livecode.com

• [ ] This tool supports creating desktop apps on more than one desktop operating system (Windows, Linux, OSX)

Anything else you want to add:

• Visual development environment and compiles to Windows, Mac, Linux, iOS, Android and web applications. Open source and commercial versions. Long established, originally based on HyperCard. Uses own scripting language.

OS:

Lang:

Pros: *

Cons: *

[marko-radosavljevic]

There is a lot of data/behaviour that would be useful to us, so we can do separation of concerns however we want. In the end we will have many representations of the elements, and that is fine in my opinion.

One of them can be visual/view-like:

• name
• description
• position
• size
• scale
• rotation
• shading
• outline (when selected, for example)
  • color
  • stroke
  • opacity
  • dotted or not
• other things required for drawing
• icons
• pins/connections and their visual data
• who knows what else we might want

These things have no importance for the actual logic of the application, they are just visual representation of the model in the editor.

If we have some complex drawing, we can have drawing/painter representation. If we are dealing with a lot of state dependent behavior, and we most likely will, we can have a state pattern/finite automata for our elements.

[weisJ]

The approach I took for the actions was to attach a Presentation object to the actions (in particular an ActionPresentation object). Each time the action is updated/is displayed an onUpdate method in which the actions gets a chance to update its presentation.

The same could be done for the elements. This way the data model isn’t cluttered with information about how it should be displayed (i.e the data model is a separate object and an element consists of a presentation and a data object).

[marko-radosavljevic]

Yup, that sounds sane. Some separation of concerns that resembles things like mvc/mvp/mvvm. onUpdate sounds like an observer pattern, etc, classic stuff.

Because there will be a lot of view-like data/behaviour in the future, much more than I mentioned before. It would be a mistake to start with adding one by one to the model. So yeah, I think we agree on the general idea.