Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add --export-tileset command line argument #1872
@bjorn Please review. Adding an --export-tileset command line arg has been quite useful to me. Also, please make sure to see the comments at L385. I believe tileset export was recently broken (the "Export..." menu item has the same behavior). Here's a sample tsx to json export to illustrate:
Hmm, that's indeed a bug. Before saving the tileset its filename needs to be temporarily set to empty, because of the following bit of code:
It would be good to change the API here so that such a hacky approach is not necessary.
Regarding this pull request, it's indeed a necessary piece of functionality and it's great that you've worked on adding it. I just hope we can find a way to add it without duplicating so much code, due to the similarities with exporting maps.
I didn't like the idea of clearing the fileName, but it was the most unobtrusive solution. Plus I figured it would get a conversation going on how to properly fix it.
The underlying problem seems to be the MapReader impl has state for whether the tileset is external, but the public wrapper sets the fileName regardless.
So the impl could set the
I can clean that up, should be pretty easy.
I think it's the wrong approach. The problem is not determining whether the tileset is external or not, it's determining when to write it out in full and when to write out only a reference to a file. The API should be able to export a tileset to a file, external or not. Only when you're writing a map file does it make sense to write an external tileset as a reference.
Looking forward to it. :-)
@bjorn Pushed a new commit to address the code duplication.
Regarding the export refactor, I get what you're saying; There's a semantic difference between being an external file and whether the output should have the full definition (i.e. embedded tilesets are not external, yet should still be written in full).
I believe we're now in agreement that the Tileset having state to dictate how it's to be exported isn't the correct way to solve this, but a proper fix would change the scope of the PR pretty dramatically so I think it'd be prudent to break that off into a separate issue. Unfortunately however, that would mean for the time being that clearing the fileName would remain. If you're planning on cutting another release soon I can add the same band-aid to the Tileset GUI export to get that working properly.
Also, what markdown are you using to inline the repo snippets into the comments? I've never seen that before, and I couldn't find anything about it in the docs.
See Creating a permanent link to a code snippet. I learned this only recently as well. :-)
I'll respond to the rest and review the new version of your patch on Tuesday.
The change looks much better now with the reduced code duplication! I've added some inline comments.
I didn't check, but I'm sure things go wrong when the user tries to use
--export-tileset at the same time, right? Since they share the
filesToOpen() list. It would be good to either fix this or to print an error in this case.
referenced this pull request
Mar 6, 2018
Thanks for your contribution!