HomeWildfire Games

Rename gui/savedgames/ to gui/savegame/ so that the page XML filename always…

Description

Rename gui/savedgames/ to gui/savegame/ so that the page XML filename always matches the directory name.

Details

Committed
elexisNov 27 2017, 7:50 PM
Parents
rP20540: Fix Builder and ProductionQueue schemas inconsistencies
Branches
Unknown
Tags
Unknown
Build Status
Buildable 3853
Build 6705: Post-Commit BuildJenkins

Event Timeline

With the exception of page_structree.xml loading reference/structuree/ that is.

@s0600204 I would propose to move non-common reference/structree/ to the (recreated) structree/ directory, rename reference/ to common_reference/ and include that from the new templates viewer page in D297.

(Also I'd prefer to rename core.js to common.js. core sounds like more like c++ code or even lower on the software stack. might just be me.)

I can do the rename if you agree, before or after D297 (you can do it too if you prefer).

Nothing will ever load from reference/structree/ except the structree page, right?

@s0600204 I would propose to move non-common reference/structree/ to the (recreated) structree/ directory, [...]

I'd prefer it if this didn't happen, as it goes against why the reference folder was created in the first place (that is, to group all reference/encyclopedia pages together). In fact, I'd like to go the other way and move gui/civinfo/ to gui/reference/civinfo/.

(Also I'd prefer to rename core.js to common.js. core sounds like more like c++ code or even lower on the software stack. might just be me.)

Doesn't really matter what it's called, that's down to personal taste (and the contents of the file). Gets included anyhow. (Would like to move the templateList generation code out to its own separate file, at some point.)

Nothing will ever load from reference/structree/ except the structree page, right?

Right.

elexis added subscribers: bb, Imarok.Nov 28 2017, 2:17 PM

As far as I understood the moving was about splitting common code that will be used by both GUI pages to a new directory. Fully agree with that.

But as long as we have a gui/page_foo.xml, it is less complex if the GUI page code is in gui/foo/, rather than in gui/bar/foo/ with unrelated things in gui/bar/.
It would mean only having one pattern globally instead of every GUI page having the choice to do a unique pattern.
Thus the reader can notice all GUI page directories on first sight without having to read the includes.

@Imarok @bb do you agree?

I kind of agree with both of you.

A 1-level directory pattern would also ease writing of gui tests

What about a compromise by calling the directories 'reference_civinfo' and 'reference_strcutree'?

I kind of agree with both of you.

You mean having only one directory pattern while still keeping two GUI pages in gui/reference/?
That could also mean having a 2-tier directory structure everywhere: gui/pageset/page/ everywhere instead of gui/page/.

Not renaming gui/reference/common/ gui/common_reference/ also means that
any GUI page that wants to include that has to either be placed in gui/reference/ or include GUI code from a different pageset.

A 1-level directory pattern would also ease writing of gui tests

Tests still need to know what to load and what and how to test, and subdirectories are hardly a problem for our VFS. At least they're not in the JS simulation tests.

Also, 0ad is moddable, and if modders wish to place gui code across multiple sub-directories, and they also wish to write tests for their own code (yeah, I know, but odder things have happened) an excuse that gui tests are limited to single-level is not going to go down well.

You mean having only one directory pattern while still keeping two GUI pages in gui/reference/?

Five. Maybe six. (structree, civinfo, viewer, unittables, timeline, ...)

But as long as we have a gui/page_foo.xml [... and] the GUI page code is in [...] gui/bar/foo/ [...]

gui/page_bar_foo.xml? gui/bar/page_foo.xml?

To be honest, I realise I'm fighting a losing battle here, and it comes down to personal taste. And I can see an advantage to having a single-level pattern. I was just trying to be tidy.

Why can't page_foo_bar.xml not be for foo/bar/? Not that there is any need to have all of that in a single folder. Folders make things easier to compartmentalize, use them.

Why can't page_foo_bar.xml not be for foo/bar/? Not that there is any need to have all of that in a single folder. Folders make things easier to compartmentalize, use them.

The definition of a compartment it's contents are divided.
I'd prefer to not have gamesetup code (hero selection dialog) in the references folder for instance.
If there are only two GUI pages, then I don't see the point.
If there are going to be 5 to 6 GUI pages that are not linked to the other code, then ok for me.