Dart SDK compatibility

[benni-tec]

What could be improved

Remove requirement for dart:ui and therefore the Flutter SDK

Why should this be improved

Currently this package/parser is only usable with the Flutter SDK. However I believe there are valid use-cases for the Dart SDK. For example I'm currently working on a CLI to optimize tmx to only include the tiles actually used in a map in it's tilesets. This is not possible using the Flutter SDK.

Any risks?

This improvement would require the removal of all dart:ui dependencies. However there are only two in this project, which I replaced in the "#69-dart-sdk branch" on my fork:

• Color, which I replaced with color_models and a little bit of code for hex parsing
• Rect, which I simply replaced by dart:math's Rectangle

More information

These changes would break public contracts and therefore require some work on the flame_tiled plugin.

However I believe this would be minimal. I did not look into this further, but from what I changed this would only require converting Rect to Rectangle and casting ColorModel to Model, which is implemented in flutter_color_models.

I believe this would be worth it and I am prepared to submit PRs both here and in flame_tiled to make these rather simple changes. However if you would consider this to be too invasive, I am happy to just keep this as a fork!

[spydon]

Overall it sounds like a good idea, we've had this plan before but never done the implementation.
I'm was thinking that maybe it is a better idea to pull in the color and rect class directly in tiled.dart instead of pulling it from the third party library so that we don't have to make yet another breaking change if that library become unmaintained and we have to update something, but on the other hand we could just pull in those classes at that time then instead.

[spydon]

@kurtome @ufrshubham @jtmcdole do you have any input on this, #70 and #71?

[benni-tec]

Overall it sounds like a good idea, we've had this plan before but never done the implementation. I'm was thinking that maybe it is a better idea to pull in the color and rect class directly in tiled.dart instead of pulling it from the third party library so that we don't have to make yet another breaking change if that library become unmaintained and we have to update something, but on the other hand we could just pull in those classes at that time then instead.

Maybe I'm missing something, but nothing is ever done with both Rect and Color right?
Could Color than not just store RGBA values and thats it? There would be no need for any library at all.
(Don't know why I did not think of this before when I implemented this)

Since Rectangle comes from dart:math I think its just find to depend on it!

[benni-tec]

Oh and I forgot to mention that I needed to replace flutter_test with test but I don't think thats going to be problem since their APIs seem to be the same

[spydon]

Maybe I'm missing something, but nothing is ever done with both Rect and Color right? Could Color than not just store RGBA values and thats it? There would be no need for any library at all. (Don't know why I did not think of this before when I implemented this)

Ah yes, if that works it would be great!

Oh and I forgot to mention that I needed to replace flutter_test with test but I don't think thats going to be problem since their APIs seem to be the same

👍

[kurtome]

My only thoughts are: make sure the Color primitives play nice with Dart's canvas methods. If I remember correctly I was having issues with the hex string being a pain to deal with, so I put the hex parsing in the tiled.dart library so we could access the dart:ui color value, but also left the hex string on the structs because (in my opinion) we want to leave let users of this library access values from the tmx file

[kurtome]

Could Color than not just store RGBA values and thats it?

I think that works because then you can make a dart:ui Color easily, the problem is the hex string didn't have a built in parser in dart:ui so it was annoying to use