I'm working on an application containing a musical pattern editor, which is basically a grid divided into musical notes on the Y axis (imagine a sideways piano keyboard), and a period of time, representing a single musical measure, divided into 16 or 32 sections on the X axis. Each division would have a horizontal or vertical line, forming a visible grid. Users would click the boxes in the grid to create or delete notes. This is very close to an appropriate use case for egui_plot, with at least these exceptions:
The grid-marker labels on the axes belong to the boxes (regions), not the lines (points). Instead of drawing a marker center-aligned with the grid lines, they'd be in between adjacent lines. I could imagine a new attribute of Plot that treats the spaces rather than dividers as the labeled entities.
The overall area of the grid has a finite bound; for example, it might be 88 notes vertically (pianos have 88 keys), and 16 notes horizontally (for a typical 4/4 time signature with each of four beats divided into 4 subdivisions). There would be no reason to allow the user to zoom wider than 88 x 16 in this example. I have experimented with set_plot_bounds() inside plot.show() to clamp it to the desired bounds, but it's super-janky. I would add a new optional Plot attribute that specifies a maximum area, and enforce it properly in the egui_plot code, rather than expecting the app to do it manually. (This might also mitigate the impact of issues like emilk/egui#3656, emilk/egui#3462, and emilk/egui#970.)
There might be more changes, but this is what my research has shown so far.
Is there interest in these enhancements? I might be able to give them a try.
I'm working on an application containing a musical pattern editor, which is basically a grid divided into musical notes on the Y axis (imagine a sideways piano keyboard), and a period of time, representing a single musical measure, divided into 16 or 32 sections on the X axis. Each division would have a horizontal or vertical line, forming a visible grid. Users would click the boxes in the grid to create or delete notes. This is very close to an appropriate use case for egui_plot, with at least these exceptions:
Plotthat treats the spaces rather than dividers as the labeled entities.set_plot_bounds()insideplot.show()to clamp it to the desired bounds, but it's super-janky. I would add a new optionalPlotattribute that specifies a maximum area, and enforce it properly in theegui_plotcode, rather than expecting the app to do it manually. (This might also mitigate the impact of issues like emilk/egui#3656, emilk/egui#3462, and emilk/egui#970.)There might be more changes, but this is what my research has shown so far.
Is there interest in these enhancements? I might be able to give them a try.