Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting Source Files #70

Closed
epezent opened this issue Jun 24, 2020 · 4 comments
Closed

Splitting Source Files #70

epezent opened this issue Jun 24, 2020 · 4 comments
Labels
discussion Thread for discussions and idea generation

Comments

@epezent
Copy link
Owner

epezent commented Jun 24, 2020

ImPlot has rapidly grown to almost 5000 LOC across all of its source files. While this is by no means large, implot.cpp is becoming a bit of a pain to navigate and maintain. I anticipate that this will become more challenging as the library grows. I'm considering splitting the source files in a manner similar to ImGui:

implot.h - no change
implot_internal.h - struct declarations and inline helper functions used internally by cpp files.
implot.cpp - code related to creating Plot axes and maintaining their state (i.e. BeginPlot/EndPlot) and misc user API
implot_items.cpp - implementation and helpers related to plotting and rendering items (e.g. PlotLines, PlotBars etc)
implot_demo.cpp - no change

I'd like to get thoughts from our usual contributors and users. Specifically:

  1. Would adding 3 additional source files be an issue or turnoff for you?
  2. Could you see yourself using functionality exposed in implot_internal.h to extend/modify ImPlot if it were designed that way?
@epezent epezent added the discussion Thread for discussions and idea generation label Jun 24, 2020
@ChiefyChief23
Copy link
Contributor

Regarding 1. imo due to the small number of files even with the extension is perfectly reasonable. Bumping up to 6 files compared to 3 is no issue.

And regarding 2. If all of the structs and helper functions would be in one file just for ImPlot I think it would be easier for people to contribute and work on the library. Once again, just my opinion.

@ozlb
Copy link
Contributor

ozlb commented Jun 24, 2020

It's ok for me and i think will help extensions.
One option you should take in consideration is to distribute the as "amalgamated" version. For how is not familiar,code amalgamation consists in copying the whole source code in one single file (obviously via automated script); for instance this is quite famous one https://www.sqlite.org/amalgamation.html

@epezent
Copy link
Owner Author

epezent commented Aug 16, 2020

This refactor has been introduced as of v0.5. See #48 for more info.

@epezent epezent closed this as completed Aug 16, 2020
@ozlb
Copy link
Contributor

ozlb commented Aug 18, 2020

I update without issues; an amalgamation script will be nice option for future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Thread for discussions and idea generation
Projects
None yet
Development

No branches or pull requests

3 participants