Get/Set Drawing properties has issues with Copied Maps

[Ltheb]

Describe the bug
When making a copy of a map, using the Draw Explorer to get and set drawing properties on one map affects the copy and vice versa

To Reproduce
Steps to reproduce the behavior:

1. Create a new campaign.
2. Draw some shapes with Drawing tools; Rectangles work. For clarity, use specific colors and draw 4-6 of them.
3. Go to Map -> Copy, and make a copy of the map. You can name it whatever, or leave it as the default copy of grasslands.
4. On your new map, select new colors, and draw a rectangle.
5. Observe on the Old map, this new rectangle does not appear. This is normal.
6. Go back to the New map, and select some new color combination, (one you know you have not used) and using the Draw Explorer, set one of the preexisting shapes to be that combination with "Set Properties"
7. Pan the map so it refreshes the view. Things look normal....
8. Go back to the Old map. Note the rectangle you changed is changed there too.
9. The opposite is also true; Setting a drawing property on an old map also sets it on the copy.

Expected behavior
The maps, once copied, should be divorced from one another. While this functionality could be a cool "Feature" for some, it seems unexpected and counter-intuitive.

MapTool Info

• Version: 1.8.3
• Install: New

Desktop (please complete the following information):

• OS: Windows,
• Version 10.0.19041 Build 19041

[Phergus]

Using right-click Get Drawing ID on the original and cloned drawing will produce the same ID though the Map IDs are different.

[raygun321]

It looks like all the DrawnElement collections on the Zone have the same problem: drawables, objectDrawables, backgroundDrawables, and gmDrawables. These could all be fixed at the same time.

The main thing here is that DrawnElement contains an interface Drawable. Implementing Cloneable on Drawable things would allow them to all be cloned without a huge block of type checks.

The only real gotcha that I see is that ShapeDrawable contains the java.awt.Shape interface. Some of those are cloneable... some are not. So, we have to support each class implementing Shape separately. It looks like there are only around four underlying shapes being supported.

[Phergus]

@raygun321 so is this you volunteering to fix it?

Don't forget that drawings can be grouped via the Draw Explorer.