Move as many headers as possible out of the include folder

[jsmtux]

Headers are moved to src/core/include or src/gui/include where appropriate. This is the first change towards a separation between gui and core.

No code changes are present in this commit. The output binaries should be equivalent to the previous commit.

[Veratil]

This PR touched some submodules as well, we don't want to include those changes.

Additionally, I believe when discussing moving the headers it was to alongside the source files (same folder as), and not just into an include folder.

Also there is a merge conflict. You should rebase the changes on master.

[Rossmaxx]

I do appreciate your PR and also the fact that include/ is not a header dump, but like we discussed in #7190, It will take much more effort than just moving headers around. We already had a reorg phase, which I believe you are not familiar with. 100s of old PRs gone stale because we were cleaning up the codebase (that effort is still going on but the major part, ie renaming stuff and moving files) is over. I do plan for a reorg 2.0, which will be a precursor to a 2.0 release. We will do the moving headers part then in a better way. Till then, I would suggest you play around with your concept some more.

[jsmtux]

Thanks for the comments!
@Veratil agreed on the submodules, not the intention to touch. About the conflict, I'll wait a bit to fix, moving so many files means conflicts every few days. I'll try to rebase this PR every once in a while to check it is still relevant, though.

@Rossmaxx whenever this fits your schedule. You guys are making a lot of nice improvements and I don't want to step in at an inconvenient time.

I agree this effort will take more than moving files around, but wanted to keep changes to a minimum so that it is not painful for review. I thought it would be nice to only move here, as no bugs would be introduced this way and it would still be a step that would get us closer to the work in my prototype.

Working on my proof of concept is fun, but my goal was to prove this route for separation had some merit, and now that that's done I feel continuing to build upon that dirty code might be a bit of a waste of time... Another idea I had was to replicate the prototype on top of latest master but in a simpler and safer way, but I might spend too long and then deviate too much again 😅

[Rossmaxx]

@jsmtux i have another proposal but it might be counter intuitive. Would you mind maintaining a seperate fork till we release a 2.0 (android only because we don't want to become competition) ? And you can upstream any improvements, but keep the rearrangement stuff within your fork till we open it up. We will tell you and we can merge your project in at a convenient time.

[Spekular]

@jsmtux i have another proposal but it might be counter intuitive. Would you mind maintaining a seperate fork till we release a 2.0

Isn't core/gui separation exactly the kind of thing we'd want included in a 2.0 release? Either way, maintaining a separate branch indefinitely while waiting for something as big as 2.0 is a huge amount of effort, and I think it makes much more sense to merge gradual steps like this as early as possible.

[Rossmaxx]

Yeah you do got a point. I'd like to get a word on this from @DomClark or @PhysSong

[Rossmaxx]

This is what I felt looking at the PR.

[Rossmaxx]

I believe it's a good idea to have the headers in the same folder as the sources. No seperate src/xyz/include needed

[Rossmaxx]

Instead everything could go to src/xyz

[jsmtux]

The way I see it src/xyz/include is a very important distinction, because it marks what can be used from the outside. Let's imagine they were already separate static libraries (which will happen at some point), then in the cmake we'd do something like

ADD_LIBRARY(lmms_core STATIC <all the cpp>)
TARGET_INCLUDE_DIRS(lmms_core PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})

That way, all elements that will need to be used from gui would go into include whilst the rest would just go into src/core. If you have a look at my proof of concept branch you'll see that the exported headers were part of a separate library lmms_core_interface, but anyhow this ends up being, I think it is important to separate the headers that are used internally to the target and those that are used from outside.

My plan for the follow up PR will be to start moving everything that is possible out of src/xyz/include into src/xyz. Especially for gui, we will be able to start moving most of the headers for src/gui. The reason I didn't start here is because moving let's say ClipView.h to src/gui/clips involves changing all the includes from

#include "ClipView.h"

to

#include "clips/ClipView.h"

and I didn't want to change any code for this first PR.

What I'll try to do as soon as I get some time is to do that next part I just described so that you'll be able to see both PRs. I think that be the last step where I'll need to move a lot of files around, so I guess it'll be nice to do both parts as close as possible. If you feel like it'd be nice to do right away I can do everything on this PR, though.

[Rossmaxx]

In the previous PR you made, I saw you created seperate cmake lists for core/*, which might help in cleanup, though the splitting up of targets, that's for further future.

[Rossmaxx]

Also, i believe tracks belong to the gui/tracks.

[jsmtux]

About tracks, it is a bit problematic indeed. All the elements in tracks inherit from Track. Song and PatternStore are TrackContainers which contain a std::vector<Track> forming the backbone of the core library.

However, as you said, there is part of each of these track types that does belong in gui which is

virtual gui::TrackView * createView( gui::TrackContainerView * view ) = 0;

That's indeed one of the parts that will need some consideration when doing the core/gui separation. In my proof of concept I used TrackViewFactory to uncouple it, as you can see in TrackViewFactory.cpp. The idea is that whenever the gui needs to display a track of a given type it now calls track->createView() on it whereas in the future it will do something like trackViewFactory->createView(track, trackContainer). Probably we won't end with the same solution this time around, but the important is that no element from the gui namespace resides in core anymore.

For the moment I'd vote for keeping this class inside core, as well as all other elements that do common things even if they need to get some parts removed sooner or later.

[jsmtux]

About separate cmake lists... I'll do that 👍

[jsmtux]

In response to your comments I've gone a bit further with the change. I think it is good to open the discussion, but the last commit could be reverted in any case.
What I've done, other than rebase conflicts and create cmake lists separately, is move some of the headers in src/gui/include to the appropriate places under src/gui/. I think I've moved all the ones that aren't used by core or the plugins, the rest of them would need more extensive changes.
The only part I am not too happy about is that I added the src/ folder to the list of includes, so that source files under, for example src/gui/modals can include others under src/gui/widgets as #include "gui/widgets/GroupBox.h", for instance. But it is not too bad.
It might be worth to include this change as there won't be any more bulk moving of files and so that new commits don't include things they shouldn't. But let's see what your opinions are.