You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 1, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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 Merge Tenacity's build system #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:
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
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 insrc/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.
The text was updated successfully, but these errors were encountered: