Question/Clarification about new CFG tabs

[argonius-ch]

Hi,

first of all I very much appreciate your effort, both in terms of documentation and actual development! Many thanks!

I have just downloaded 1.40.02 (unpacked), I like the changes w.r.t the configuration tabs, but I do have some questions about it:

• The change notes state that global config is used by default, it also states that tile config is loaded when changing the active tile in map view. To me it is not fully clear which config is then applied when generating a tile. In Batch Mode there is a "Read config per tile" check box, so I'd expect global config is used in batch mode unless this check box is checked. But how about when generating a single tile using the buttons in main window? I assume tile config would be used. Maybe adding the same check box there too would make it more clear.
• The documentation differs from the change log: Additionally, the tile configuration file is not automatically loaded when you start Ortho4XP or select an active tile. After selecting a tile, the tile configuration must be loaded by selecting "Load Tile Cfg" in the Ortho4XP Config window and then click "Apply".
  (Guess doc has just not yet been updated)
• Suggestion: Since global config is the default config, I propose to have it as the first tab (instead of tile config). Otherwise people might end up editing tile config by accident.

keep up the great work!

[shred86]

That's my fault - I originally started writing the Wiki based on the original version of the application and haven't made any updates since I started modifying the application. I just made a couple updates to hopefully avoid confusion but I plan on trying to make more updates later today or this week.

Update: Just deleted a comment I made as it's not completely accurate. I'll update this here shortly.

Update 2: Sorry about that, I had to look at the source code again as I was starting to confuse myself.

When building a single tile from the main window, it will use the tile configuration file. If it doesn't exist, it uses whatever is "loaded" in the application at the time. If this is the first time opening Ortho4XP, that would be the global settings since that's what it defaults to. Now that we're loading the config each time you change tiles, you're basically going to get the global settings by default if that tile doesn't have its own configuration.

When building multiple tiles (batch build), if you do not have "Read per tile cfg" selected, it will use whatever you have in the Tile Config tab at the time for all tiles. If it is selected, then it will first look for a tile config file and if it doesn't exist, use whatever is "loaded" in the application at the time, which is essentially what's on the Tile Config tab.

I know this isn't the most intuitive right now and it's something I'm continuing to work on. I'm likely going to change the case where if you batch build without "read per tile cfg" selected, it will use the global settings (like you mentioned) since I think that is what makes the most sense.

Any thoughts/ideas are always welcome.

[argonius-ch]

This is an attempt for structuring the whole story a bit - for discussion...

We have two types of config files - one lives in the main application directory, one is created in each tile folder when building the tile. It seems natural to consider the first type being the global config, the second type being the tile config.

Ordering of tabs:

1. Global config
2. Tile config
3. Application config

Launching the app:
When launching the app we load the content of the config file in the main folder into global config tab, the content of the config file of the active tile into tile config tab. If there is no config file for the active tile, tile config tab remains empty. There are buttons to populate the tile config tab with the date from global config or with default values.

Changing the active tile:

• the tile config is loaded into tile config tab, if the file exists, otherwise it remains empty (i.e. removing the values from a previous active tile)

Batch Tile creation:

• If "read per tile cfg" is checked it will do exactly that, reading the stored per tile config file. We could fallback to global config in case there is no tile config file.
• if "read per tile cfg" is unchecked it uses the global config parameters
• During the process a tile config file is generated on stored in the tile folder

Single Tile creation from main window:

• This always works on the active tile, so we do have the respective tile config loaded in the tile config tab (if existing)
• Add a new check box "use tile cfg", unchecked by default
• If "use tile cfg" is checked, the tile will be created using the tile config, if empty we throw an error message
• If "use tile cfg" is unchecked, the tile will be created using the global config
• During the process a tile config file is generated and stored in the tile folder

Creating a tile config (e.g. prior to batch run):

• let's assume we have an active tile w/o tile cfg stored and we want to modify the global config for this tile only
• Populate the tile config with the data from global config by pressing the respective button
• Change the tile config parameters as desired.
• Press "save tile config", the cfg is written to the the tile folder

It think with this approach, we'd have a consistent use of global vs. tile config throughout the workflows.

[shred86]

Thanks for taking the time to lay that out! I actually just pushed a change to my dev branch that makes a couple small changes but here's some thoughts on what you mentioned.

I've also considered blanking out (or making the fields read-only) the Tile Tab values if no tile configuration exists, but another thought I had was maybe just adding a little status text string/indication at the top of the page that lets you know if a tile config was found and loaded or if the defaults are being used.

For batch tile creation, I just changed the default behavior to use a tile config if it exists, otherwise use the global config. The "Read per tile cfg" was removed since this is now the default behavior (although previously it wasn't reverting to the global config but it is now), and I changed it to a new setting called "Override tile cfg" (might be a better way to phrase this). If you select this option, it will basically force the global config on all tiles, overriding/overwriting your existing tile configs (if they exist).

For single tile creation, whether it's from the main window or batch building a single tile, the logic remains the same - use the tile config if it exists or the global config.

I thought this approach kept it simple and consistent, whether you're building a single tile from the main window, a single tile from batch build or multiple tiles from batch build. The exception would be batch building provides an option to force the global config.

I haven't used Ortho4XP for long, so my use case has been pretty basic so far of just defining custom zoom levels. However, I'm starting to see the potential need to look at the global config as more of a template and being able to assign them to a tile. For example, I might want to change some of my settings in mountainous regions compared to flat regions.

[shred86]

Here's another idea - turning the fields to read only when no tile configuration exists and just display the global settings. I also put a status message at the top (this is just a quick prototype so the wording, layout and formatting is all subject to change), although I'm not sure if it's needed. The thought with this idea is that it lets the user know, these are the settings that will be used and they're coming from the global config.

• All fields are read-only since the global config settings will be used.
• If the global settings are updated and saved, it will be reflected on the tile tab as well.
• To create a tile config, the user would click "Save Tile Config" and now everything becomes editable since a tile config exists.

[argonius-ch]

For batch tile creation, I just changed the default behavior to use a tile config if it exists, otherwise use the global config. The "Read per tile cfg" was removed since this is now the default behavior (although previously it wasn't reverting to the global config but it is now), and I changed it to a new setting called "Override tile cfg" (might be a better way to phrase this). If you select this option, it will basically force the global config on all tiles, overriding/overwriting your existing tile configs (if they exist).

For single tile creation, whether it's from the main window or batch building a single tile, the logic remains the same - use the tile config if it exists or the global config.

I thought this approach kept it simple and consistent, whether you're building a single tile from the main window, a single tile from batch build or multiple tiles from batch build. The exception would be batch building provides an option to force the global config.

I like these changes, I think it is more straight forward and consistent now.

I haven't used Ortho4XP for long, so my use case has been pretty basic so far of just defining custom zoom levels. However, I'm starting to see the potential need to look at the global config as more of a template and being able to assign them to a tile. For example, I might want to change some of my settings in mountainous regions compared to flat regions.

One use case to be considered is also re-doing tiles. In this case you may want ignore the existing tile config and use a new config. With above changes this can be easily achieved with the "Override tile cfg" option.

[argonius-ch]

With having global config as sort of template, maybe this proposal could also be addressed by adding a open file option: oscarpilote#238

[shred86]

Just pushed my latest changes to the dev branch if you want to check it out. I'm just testing it out to make sure I didn't miss anything and I think I'll do a 1.40.03 release since there's been a decent amount of changes.

That proposal is actually what prompted the idea of templates. That's going to be a bit of work though so not sure when I'll be able to get to it, but I do think it would be a nice feature.