Combine Scribe and Foundry into one Editor

[mchlnix]

Inviting @fortenbt to chime in.

History

This was initially the plan since there was a time, when Foundry allowed opening world maps and even changing their layout (although I don't remember if it saved or how usable it was).

But since I made that "feature" inaccessible, it clearly wasn't up to par, if even functional. Foundry and Scribe share a lot of code, like a MainWindow and a MainView class, which I went to some lengths to, to make actual parent classes with little duplicated code in its children. And of course Settings Menus, Dialog Boxes and the UndoStack implementation are mostly the same.

But editing a Worldmap and Editing a Level seems to be quite different, to the point, that, when I sat down again last Summer, I found it was more straight forward to make Scribe its own thing. Without reusing the Editing Interface of Foundry.

UI differences

Objects in the World/Level

In Levels the objects are generators, which can produce either small 1-Block objects, like coin blocks, to gigantic mazes, like in the desert level. They are all their own thing and there are usually less than 100 of them in a level, both of which makes it sensible and sometimes necessary to list them on the side of the Editor.

Some of them can also be manipulated, when it comes to their size, in width and/or height, which is something that can be done in the LevelView itself. They can also be on top of each other, making it necessary to give the user control over the z-position of the Objects as well, which luckily can be dealt with by changing the order of the objects in the Level.

Enemies are separate from Objects in Levels, but work mostly the same. They have a set size, so are easier to handle.

Objects in a World are different. Tiles, the ones making up the layout, so comparable to the Level Objects are all just 1 Block in size and are often just building blocks. Rarely do they stand on their own like "Fortress". They do not change size, either and there can only be one Tile at any given Position, meaning there is no z-Position.

Other Objects, like Level Pointers (defining which level one gets to, from which Tile), Sprites, which are limited to 9 and Locks are also world dependent. They behave like Enemies, in that they can overlap and have a fixed size, but have other attributes to consider, too.

There is no analog to this additional data in a Level Object or Enemy (although that might not be a bad idea, see #145).

The solution for all this additional data and for easily selecting the different Tiles was the ToolWindow in Scribe. While the fewer in number and more distinctive Level Objects can better be shown in a Toolbar, separated from each other.

I don't see a fusion, which isn't a bad compromise for both. So both would have to be kept.

Header vs Level vs World (vs ROM?) Settings

The Level Header has a lot of individual settings, which an Overworld barely has. They share Music and Palette and Mario Start Position settings, but no more (off the top of my head). Same as the Level Settings, which are mostly to hide complexity of some special Level Objects, like Chest Pointers, Pipe Pairs and others. Long Story Short, those dialogs should also stay separate.

LevelView vs WorldView Settings

There are also special Overlays for certain Level Mechanics and World Objects. They are each already pretty long, so merging them, when there is only one of those sets actionable seems like a bad idea again.

Editing World and Level together

Editing the Layout of Worlds in Scribe, while also changing the order of other Worlds or their screen number is already a small challenge, since those "rom-wide" changes would need to be kept, until the world is saved and restored, if not. Having multiple Levels or Worlds open, while also making the order of Worlds editable and the level positions would add another layer or two to all this information, some saved, some not, which have to be kept square at all times.

Maybe only allowing Rom-Wide changes, while no other Levels are open are the solution to that?

---

There are certainly other considerations still, but the situation seems to be, from a code structure point of view it is doable, since Scribe builds upon the GUI widgets of Foundry and there is considerable overlap, but from a Editing Interface point of View they seem almost orthogonal.

This doesn't need to be a huge problem, since, depending on what kind of level is open, Level or World, we can just switch out the Menus, visible Widgets, Undostacks (if we want to allow multiple Level and WorldViews in Tabs) and to some part logic, but rewiring the whole GUI, so that Qt Signals are set up correctly, every time the user changes a Tab or even just loads a World after editing a Level could be kind of brittle, even if the LevelRef class already tries to decouple the Signals of the levels themselves.

So at the moment, I don't see a big advantage of merging both tools, unless all of this is resolved in a nice package, which would need to be worked out in this issue.