Make Our Own Library Separation Effort

[generic-pers0n]

We should be making an effort similar to Audacity's library separation efforts. I am not suggesting that we backport Audacity's efforts into Saucedacity's code base, but rather we should do the library separation ourselves in a similar nature to Audacity's efforts. For example, we should move Saucedacity's audio IO code into it's own library. We can also make that library available for general use, but that's for another issue.

Benefits

The benefits of separating parts of Saucedacity into several libraries helps with moving away from wxWidgets. Additionally, it can help with organizing Saucedacity's code base.

Why we should make our own efforts intstead of backporting Audacity's efforts

Before I go on: I will make it clear that **I am NOT opposed to backporting Audacity's library separation efforts. In fact, I've already done this with lib-ffmpeg-support (which currently resides in src/ffmpeg instead of being an actual library).

I believe that separating libraries in our own way will be more productive. Doing this effort ourselves can help us save time trying to figure out which pieces of the puzzle go where. This is especially considering that as time goes by, our code bases will continue to diverge from each other. As time progresses, I feel it will become virtually impossible to catch up with Audacity's separation efforts. Right now already, I believe there is already quite a bit of work required to catch up. Nevertheless, I like and even agree Audacity's idea of separating parts of their code base into different libraries.

[generic-pers0n]

Library Ideas

• lib-xml - Moving all of Sauxedacity's XML handling code (mostly stuff in src/xml) into this library. Will not depend on wxWidgets (ideally). Efforts currently under way
  • Target Saucedacity would no longer directly depend on expat. It would now depend on this library (as far as I can tell).
  • We can also devendor expat in the process, but that would coincide with #45, so that would take priority.
• lib-widgets - Moving all of Saucedacity's custom widgets (excluding toolbars and track widgets...for now). Mostly found in src/widgets. Will depend on wxWidgets. Currently an idea
• lib-toolbars - All of Saucedacity's toolbars, rewritten to be toolkit neutral like lib-basic-ui. We can then provide our existing toolbars as an implementation. Currently an idea.

More reasons as to why we should make our own library separation efforts

• The more libraries we have that don't depend on wxWidgets, the less code we will have to rewrite.
• This provides a cleaner separation of Saucedacity's core architecture:
  • Each library is its own part of the program.

[Rossmaxx]

One suggestion i have is to seperate the core from the gui. Lmms has it planned for 1.3 (or a post 1.3 release cause 1.3 is already too delayed) The lmms team recently finished a huge reorg where they cleaned up their entire codebase. It took an entire year with a lot of active devs and hundreds of prs but it is making development easier