Standardize UI windows

[zaxhutchinson]

From the homepage, the advanced config opens a new toplevel window. Unless I'm mistaken, about and game, do not. I would like to standardize this before implementing any additional UI changes.

My thoughts are to have only 1 top level window from which the others branch off. And provide a "back" or "close" button to return to the previous screen. While I like the idea of giving everything its own window, I think it could create confusion if someone is trying to edit configs with the sim window open. And it might be nightmare to make sure it all syncs if they try to launch a sim using new changes.

Here are my plans currently:

1. Bring advanced config in line with the others and make it a frame. Since I didn't write it, I'm not sure if there are Tk requirements that it be a toplevel.
2. Add "back" button to go back to the homepage where necessary. It looks like about has one and the game needs one. These need to be standardized and all in the same place so there's no confusion what they do.
3. Longer term project: break up advanced config into multiple config screens. Basically one for each column. This would provide room for all map config info to be on the same screen once "in-config" map creation is a thing.

[zaxhutchinson]

1 On branch ui_work, I've pushed a revamped navigation from the home screen. Only the team config has been worked over. I refactored much of the code and reimagined some of the UI to allow for entering multiple agents. I'm relatively happy with the UI changes. However, I'm not super happy how saving to the team_data is automatic for some operations like add agent, but not for others, like if you change an agent's callsign you have to click update agent. It's not very intuitive and I can see users changing the agent data and not realizing it isn't an automatic writeback. SOoooooo. The only idea I have is to give each field an "update" button to make it explicit.

2 There's a question how to handle the JSON data during config operations. It only occurred to me at the end of this work. It goes like this:

I think the loader should be the single storage point for all data. Config screens should not keep copies of the data (which is what we've done so far). I reduced the number of copies in Team Config, centralizing it to one variable (self.team_data), but I'm not happy with it.

Reason is: the config screens are not destroyed if one skips back to home and then to another config. It means some local data might not have been saved back to the json (or even the loader, which now that I think about it, isn't updated at all) in one and is not available to another. They should all have access to the same data.

Rather than making each config screen responsible for saving its data to the json. We push saving to the file back into the loader (it becomes a json proxy essentially). And each config screen is only responsible for keeping loader up-to-date. Other than a reference to the loader, it doesn't keep permanent data.

• Add/Delete/Update: will all alter loader's data.
• Save X to JSON: will save only that screen's data (e.g., teams) back to the json.
• Save All to JSON: will save all loader data back to the json.

I'm not sure the last one is strictly necessary. It could be button on the home screen giving the user the option to save everything before quitting. Just to make sure they haven't missed anything.

[zaxhutchinson]

Most recent commit to the ui_work branch implements number 2 of the above post for the teams config screen only. I haven't added in a SAVE_ALL, but I think that should only be on the home screen. Going to work on other config screens. I think components next.

[zaxhutchinson]

Component config revamped and re-enabled. A component's ctype must be specified on creation. I made a new component creation popup window that asks for id, name and ctype (from dropdown). 1) it doesn't make sense to change ctypes once a comp has been created. 2) Complicate the code.

Comps aren't so complicated that deleting a misstep would a problem.

[zaxhutchinson]

Object config revamp is pushed to ui_work branch.

I am taking the opportunity to rework some of the json data. So, either as a final step in this branch or in another subsequent branch, I'll need to go through the rest of the program and find what I'm breaking. I know I've broken some stuff with objects (renamed some of the fields).

I'm starting work on the map config/painter. And I have decided to completely rework how maps are stored. Still json.

[zaxhutchinson]

Map config work is coming along. I've revamped the interface and am bogged down in slowly adding all the functionality. With the latest commit, you can draw and remove objects from the map. And starting locations are drawn.

Edge objects are generated automatically for the visual and cannot be removed via the map editor (since they aren't in the object json obj.

Major things remaining:

1. Create/delete/update sides
2. Add/remove starting locations for each side
3. Add/remove items (not far on this, but it made me realize we need an item config page).

[zaxhutchinson]

Pushed the first version of revamped map config screen. It is by far the most complex of the config screens since maps tie together all other aspects of the simulation.

I took the opportunity to sanitize some of the JSON file structures. With this map revamp I've likely broken the simulation itself (haven't tested). There are a few JSON changes that will cause issues. But the most fundamental change is that the loader class stores only templates (i.e., the raw JSON data). And it only builds objects when requested. This allows the config screens to deal only with JSON and not with classes/objects meant for the simulation. This will require a little interface rework between the sim (and its classes) and the loader. Shouldn't be bad though.

Way too many changes to document properly. But a few are:

• Each side can only have 1 gstate (changed from a list).
• gstates entries in the JSON are no longer lists of gstates, but just individual ones. Not sure why I did that originally. I might find the reason later when fixing the sim.
• only 1 copy of an item can be on a map. Ex: can't have 2 blue flags on the same map. If a map idea requires conceptually identical items, you will need to create different items in the JSON with unique IDs. This reminds me: I think commands to the 'arm' component use item names. Currently, item names don't have to be unique. I'm not sure how this is handled in the code. If there are two 'blue flag' items and an arm comp is instructed to pick up a blue flag, what happens? Not sure. Seems like I handled this...
• Altered the map constraints for items, objects and starting locations. Objects and starting locations are mutually exclusive. Can only have 1 of either in a cell. Items however can be anywhere...even with objects. I left that possibility so that one could model items hidden in objects. But there's no code that "hides" items if an object is present. To get the item, you'd need to destroy the object to move into the hex to pick up the item. So, yeah. Future work.
• And more than 1 item can be in a cell.
• Updating maps (and this goes for other configs as well) isn't 100% clear. Some things get updated in the loader's data automatically. For example, if you add a new starting location, the underlying JSON is altered without having to click the "Update Side" or "Update map" button. However, if you want to change the name of a map, you must click "Update Map". To be on the safe side, docs should suggest clicking "Update Side" if you have made any side-related changes. "Update Map" if you have made and map or side changes. And click "Save to JSON" if you're content with the map and want to store it for later. Regardless: only saving to JSON will make changes permanent. Only that button writes back to the file ON ALL CONFIG SCREENS.

There are two config screens left to do: gstate and items. They are pretty straight-forward.

Once these are done, I plan on testing the config suite and documenting the code, tweaks, etc.

[zaxhutchinson]

I take back what I said (partially). goal state config is actually stupidly complicated for how little info each one has.

Items were pretty easy though. Not pushed yet. Still working.

[zaxhutchinson]

For the time being, I've disabled use of the tkmacos package. Several times now I've run into bugs that when I look at the call stack, tkmacos is in the stack. Although I only see it being used explicitly for uiButton, it appears in other places too. I'm not sure why. It required altering the button width/heights.

I'll revisit the package once everything is back up.

[zaxhutchinson]

Goal state config seems mostly ok.

Revamping goal config brought up a few questions:

• object/item ids need to be stored...not names.
• how do we handle more than one of the same type of object in a goal? In a match, gstates store references to the in-play objects and check if they've been destroyed. But to store the references, there is an initial comparison. There would be a problem if someone wanted to set the state to one object of several identical ones.