Suggestion: put chart in a separate crate

[7jrxt42BxFZo4iAnN4CX]

It would be possible to separate the chart rendering into a separate crate.
At least a candlestick chart, and you can call it iced-candlestick.
If that's possible.

[akenshaw]

I’ve been looking into this, but all the chart types unfortunately very tightly coupled to each other, like they are “glued-in” mess to the working code. I’ve done them in a very hacky way just to get them somewhat working, so separating even some part of it for something like “candlestick chart” API for Iced wouldn’t be usable without the exact same context

I do look forward for a full rework on charts though. For example “autoscaling” not existing is a limitation from how the charts implemented, or CandlestickChart having different zoom in/out dynamics compared to traditional way of zooming for bar charts, like on Tradingview. So until that full rework first, i don’t see much benefit of separating charts in a crate

Also, there are much better structured APIs exists like kunerd/pliced or Joylei/plotters-iced. If someone wants to plot candlestick/timeseries charts with Iced, these would be much better choice to start off from

[7jrxt42BxFZo4iAnN4CX]

Got it, that's ok.
It seems you used plotters-iced before and the performance was worse. Waiting for the update, I'll try to test it.

There was an idea to build charts by selecting data from the database (10-15 charts in a window and buttons to select the next ones). But maybe I'll do it in js, it's not so critical.

By the way, here's a channel on YouTube, maybe it will be interesting/useful - youtube.com/@anthonygg_

[akenshaw]

Yeah i’ve seen that guy on crypto twitter, he was building a similar charting platform, and promoting by shitting on other ones, no? 😄

I switched to custom charts not because of performance reasons but just needed more customization and a bit more control. plotters-iced would still be totally fine for candlestick/footprint charts. Main performance improvement came later on the same backend, but with optimizing how we draw historical orderbook on HeatmapChart

What do you see that its lacking for your idea, is it the performance with 10-15 charts? Im confused you mentioning Javascript, do you mean that you wanted to implement charts we have here to another platform?

[7jrxt42BxFZo4iAnN4CX]

To be honest, I hardly watched his videos, since he writes the project in Go(not interesting) and it is not open source. But I remembered this project when I saw it.

JS is mentioned as an option for possibly faster writing. And initially there was an idea of ​​normal charts in native implementation, with a good response. I was also interested in iced, because of some of the hype around COSMIC DE. I haven't decided yet, I just don't have enough time.

What other platform can this be implemented for?

[akenshaw]

I mean you can translate the drawing part well into HTML canvas pretty straightforward, and like looking at how i prepare data and whatnot. They are pretty much the same as we just draw 2d shapes, and not dealing with low-level stuff. I even would say i had much better time using Iced’s Canvas compared to HTML’s Canvas. Iced’s API perfectly aligns with how Rust wants you to structure your code design naturally, which in turn actually making it easier to implement a maintainable code

I was just asking because i thought there is a shortcoming or something that you want to see on this project, was just curios what that was, as you want to do a whole another implementation

[7jrxt42BxFZo4iAnN4CX]

Everything is much simpler. Just have an alternative to plotters-iced, provided that I know that the implementation in this project works, as I tested it. Well, from the point of structuring the code, the separation of projects looks logical. And those who would use the new rendering implementation could help improve it.

[toanngosy]

@akenshaw probably we may need to refactor the code so if someone want to add custom indicator he can do it as a plugin/extension. On a conceptual level, heatmap we can treat it as a layer indicator, that on top of a chart (can be candle or footprint), while volume and OI is a widget indicator.

[akenshaw]

@akenshaw probably we may need to refactor the code so if someone want to add custom indicator he can do it as a plugin/extension. On a conceptual level, heatmap we can treat it as a layer indicator, that on top of a chart (can be candle or footprint), while volume and OI is a widget indicator.

I’ve tried to avoid dynamic dispatch traits in the whole codebase back then, which led to bunch of the plumbing/boilerplate caused by match arms to add a new indicator into UI menus, bringing into chart update logic etc...

So might look into Box<dyn Indicator> to reduce most of that plumbing, but if you mean “plugin/extension” = no-plumbing, that would require us to write whole new scripting layer, a DSL(could be done with proc-macros maybe), to go full Tradingview/aggr.trade way. That i dont think it should be prioritized, seems like way out of scope for now

[toanngosy]

@akenshaw probably we may need to refactor the code so if someone want to add custom indicator he can do it as a plugin/extension. On a conceptual level, heatmap we can treat it as a layer indicator, that on top of a chart (can be candle or footprint), while volume and OI is a widget indicator.

I’ve tried to avoid dynamic dispatch traits in the whole codebase back then, which led to bunch of the plumbing/boilerplate caused by match arms to add a new indicator into UI menus, bringing into chart update logic etc...

So might look into Box<dyn Indicator> to reduce most of that plumbing, but if you mean “plugin/extension” = no-plumbing, that would require us to write whole new scripting layer, a DSL(could be done with proc-macros maybe), to go full Tradingview/aggr.trade way. That i dont think it should be prioritized, seems like way out of scope for now

Right, I mean the Box, and futher decoupling between data and indicators to make implementing new indicators easier.