This file needs dealing with.

Possible additional fields required for TextGraphic and TextOutline, in particular baseLine.

Although designed with performance very much in mind. Area selection and reduced object generation at small scales, has not been implemented.

Part of this is implementing adjacent tile addition. I think I want to implement #26 before dealing with this.

The dependency direction between these packages is not clear. Could be none, either way or mutual.

Core/ostrat.pDev.Play worked quite well for me as a lone developer. However it means that changes back and forth to the contributors working app get committed as source code changes. it would be better if this was a run time argument. Will need to check if this is a problem for Scala.js.

In particular check html.canvas.onwheel and possibly make pull request for scala.js.dom to add method.

Add flags to pStrat.Flags. Some flags may require the implementation of Bezier curves, issue #7. many do not.

offending line 10:
<script type='text/javascript'>ostrat.pSJs.JsPlay().main();</script>

Using Scala Native is an essential part of the long term plan. However I feel given the use of specialist collections I feel its vital to move to Scala 2.13 and the new collections library early. Currently there are dependencies on Scala.js and ScalaFx. I don't anticipate any problems with Scala.js, but I'm not sure about the prospects for ScalaFx and 2.13. ScalaFx could probably be removed and we could rely directly on JavaFx.

Scala Native is currently on 2.11, so I don't think Scala Native should be allowed to hold back our move to 2.13.

I had thought at some point to offer multiple canvasses to utilise multiple displays. Not sure if that would create difficulties in the browser. In which case it might be helpful to separate the platform from the canvas. At the moment the only thing that the platform offers aside apart from canvas funtionality is saveFile and loadFile methods and some helper methods based on loadFile.

Although an integral part of the design, tile sides have not been implemented. I have gone back and forth on whether tile sides should be separate objects, or should be part of a tile. There is a related point of whether vertices should be separate objects.

I chose the name "rich" as a root package name when all my code was closed source. It tied in with my use of the richstrat.com domain. I intend to keep richstrat.com as my own privately owned domain and richstrat as my own private marketing name if I decide to commercialise my work in the future. The use of package name is therefore potentially imprecise and misleading.

Possible replacements "ostrat".

/** This is an active visual canvas object. Not sure about the name. not sure if the trait is useful. */
trait GraphicSubject[A <: GraphicSubject[A]] extends GraphicElem[A] with GraphicActive

Is this trait useful and if so is there a better name.

I have made this low priority, because I don't feel I have anything particularly innovative to offer in terms of servers. Other features where I feel I do having something innovative to offer have been given high priority, in particular #48.

I think this justifies its cost. Short infix names and operators should be used judiciously, especially on common types like Doubles and Ints. I suggest "vv".
val v1: Vec2 = 2.7 vv -3.82
I think this works quite well, vv having having lower precedence than arithmetic operators.

Suggest modifying the CanvObj trait so it has a precedence value. Ie which objects lie in foreground and background. Suggest restricting value range to (-4 to +4). This will obviate the need for the Disp2 trait.

The purpose and implementations of this package are not clear.

Replace fTrans(tlCen)) with an implicit method.

Array[Double] based collection for geom.CurveSegs

These will be renamed to PolyFill, PolyDraw, ShapeFillDraw etc

Consider extending hexadecimal to 32 values for succinct tile coordinate notation. Uses all the letters except i and o. 2 digits can encode 1024 vales instead of 100. 3 digits can encode 32768 values instead of a thousand.

0123456789ABCDEF //Hexadecimal

0123456789ABCDEFGHJKLMNPQRSTUVWXYZ

So classically canvas is a feature that is offered within the GUI API. I think this conceptual frame work is fundamentally flawed. I think the first thing we need need to do is to distinguish between applications and text based documents.

In a document the text is the centre of the content, functionally but often literally. The classic web page, where you start at the top and scroll down, works rather well. There maybe numerous pictures, videos, links and controls, but they are all there to support the text. It seems to me that the basic idea of Javascript and PHP as supportive tools to text centred documents was correct, however dated and dysfunctional the implementations. This is very different from a GUI application.

In a GUI application the text supports the windows / scenes / stages /sub- applications of the GUI App. It is for these GUI applications that I think the canvas / gui split is mistaken. I want to move to a situation where the canvas is the GUI and the GUI is the canvas. I believe in Scala we can do a much better job. So the abstract canvas is not intended merely as away to write cross platform canvas code, but to replace the whole GUI API.

Suggest modifying the GraphicElem trait so it has a precedence value. Ie which objects lie in foreground and background. Suggest restricting value range to (-4 to +4). This will obviate the need for the Disp2 trait.

Not sure if GraphicSubject trait is useful. Not sure if it is necessary in addition to GraphicActive trait.

Active / pointable display objects return an AnyRef, when the use clicks within the polygon / shape of the object. The application GUI receives a list of these reference objects within which the user has clicked ordered from front to back of the display. So consider using an integer or a long and a lookup table, to enable pure value types. Suspect this is unnecessary and that performance problems are due to too many calls on the plaform's canvas graphics engine (particularly for JavaScript), rather than the preprocessing of a frame.

Core test is broken in sbt. The tests won't compile, but they are working fine in Mill. I've delayed bumping the uTest version.

Fill in EuropeEastGrid in Core/ostrat.pEarth.EuropeEast.scala. Hopefully should be self explanatory.

Currently only producing Docs for Core FxStrat

The method in Line2s needs to be generalised.

Consider removal of ife and other Boolean extensions.

I'm not sure if this code's long term existence is justified. I'm not sure if it provides sufficient advantage over using a library, maybe Scala-tags, maybe something else. I've had a closer look at Scala-tags and I don't find it succinct enough.

Most of the code was written before I aware of Scala-tags existence. I'm not sure if I can give it the time and focus that it would need. However I have been using this code regularly for web site generation. I'm not sure if it can and should be integrated with my RSON (Rich Succinct Object notation) as part of a hierarchical code / data abstraction, generation and manipulation.

I am very happy with my RSON, although it needs significant development and I'm not sure about the the first word of the name.

The onwheel call in JsStrat/src/ostrat/pSJs/CanvasJs.scala is giving a reference error in the browser.

Add Bezier curves to Line segments and Arcs as Shape components.

planining to have a few exceptions - willing to be overruled!
eg Object => Obj

These classes are currently implemented as Array[Double]s. But this is completely pointless, as they will never be in collections such as List[FillPoly] or List[FillDraw], so they will always need to be boxed. The lesson is don't try and make value classes out of indeterminate length objects.

Look at and possibly remove implicit class ImpVec2Traversible[Repr](travLike: TraversableLike[Vec2, Repr])

So currently arcs and beziers are being treated as straight lines.