kbhearn wrote:single file has the advantage of ease of distribution/configuration. you just have to point the gui at a single file. i assume most graphics editors would allow you to use a layer per piece and assign custom ids to the layers, but if not you could always use text editing to combine seperate files later.
While this is true, it becomes much harder to customise things. Say you only want to modify one piece image: you now need to duplicate all other piece images as well. What if an original piece changes and you want to import those changes into your modified piece set? You now need to edit the combined file.
Of course, I may be used to how XBoard handles this, but multiple images packed in one file strikes me as solving a problem that can easily be solved in a different way, while introducing new complications of its own.
If instead of a file you point to a directory of piece images (with standardised names, but you do that with layers anyway) you solve both problems: you can have a "default" set to fall back to if a piece is not found in the requested theme, so you never need to duplicate a piece; even if you do, updating is as easy as copying a file.
So from a maintainability/scalability point of view, I think one file per piece image is superior...
kbhearn wrote:single file has the advantage of ease of distribution/configuration. you just have to point the gui at a single file. i assume most graphics editors would allow you to use a layer per piece and assign custom ids to the layers, but if not you could always use text editing to combine seperate files later.
While this is true, it becomes much harder to customise things. Say you only want to modify one piece image: you now need to duplicate all other piece images as well. What if an original piece changes and you want to import those changes into your modified piece set? You now need to edit the combined file.
Of course, I may be used to how XBoard handles this, but multiple images packed in one file strikes me as solving a problem that can easily be solved in a different way, while introducing new complications of its own.
If instead of a file you point to a directory of piece images (with standardised names, but you do that with layers anyway) you solve both problems: you can have a "default" set to fall back to if a piece is not found in the requested theme, so you never need to duplicate a piece; even if you do, updating is as easy as copying a file.
So from a maintainability/scalability point of view, I think one file per piece image is superior...
I'm not sure if you're familiar with the SVG (Scalable Vector Graphics) format. It's XML-based and quite different from traditional bitmap formats. Having multiple elements with unique IDs in an SVG file is really not much different from having multiple functions in a single C (or whatever programming language) source file - the elements can be freely moved and scaled around, their position and size in the image doesn't matter, and making changes to a single element only produces a small text diff, just like editing a single function in a source code file.
Anyway, this is such a small implementation detail with negligible performance impact that I would say the best solution is to keep using whatever scheme you're already using.
kbhearn wrote:single file has the advantage of ease of distribution/configuration. you just have to point the gui at a single file. i assume most graphics editors would allow you to use a layer per piece and assign custom ids to the layers, but if not you could always use text editing to combine seperate files later.
Sorry I don't buy that. How is pointing to a file any easier or more difficult then pointing to a folder? And if I have to open multiple applications to get something to work right, that's not easier.
The problem with this whole idea is all applications that use svg images for their pieces use one piece per image. You've made the prospect of porting those images to your arbitrary format a much more difficult task thereby ensuring that it most likely will not happen. Its not just a matter of copying paste on top of each other, you must make sure your pieces are grouped appropriately, which a lot of ones I've seen that already exist are not. All this added effort is more then reason not to do it that way.
How do you take into account positioning? Do you have 6 pieces layered on top of each other? Sorry but the way SVG images are in inkscape with images consisting of multiple parts, you've made editing each piece and determining which part goes to which piece a possibly total mess.
Well, I don't think it would happen much that people wanted to replace a single piece image in a piece set (if at all). Browsing to a folder with individual images or to a single file of packed images makes no difference from the user's point of view. So I don't think that you could say one system is better than another.
Ilari is right in stating that this is just a small implementation detail. But that is from a developer point of view. Because this implementation detail happens to affect compatibility with existing systems, it potentially has a big impact on future users however.
Joshua and I have spent a lot of time earlier this year to collect all kinds of different piece graphics, and package those in a universal way (including a makefile for doing the install). I just think it would be a big boon for the user if such packages could be interchanged between GUIs. Would it be possible to convert sets of individual SVGs into such amulti-image file through in install script?
After a small interruption because bloody Windows felt it was time to reboot my laptop for updates:
There would always a problem in using a piece-image package for multiple applications, as each application would expect them in different places. E.g. XBoard expects them in /usr(/local)/share/games/xboard/themes/*, while cutichess-gui (to comply with Linux standards) would expect them in a place like /usr(/local)/share/games/cutechess/... So in any case different things would need to happen when installing for XBoard or cutechess-gui.
When installing from source this could be easily solved by having different make targets for both installs, like "make install-xboard" or "make install-cutechess". As binary package that would not seem possible, though, as the make target would have to be chosen at packaging time.
ilari wrote:
I'm not sure if you're familiar with the SVG (Scalable Vector Graphics) format. It's XML-based and quite different from traditional bitmap formats. Having multiple elements with unique IDs in an SVG file is really not much different from having multiple functions in a single C (or whatever programming language) source file - the elements can be freely moved and scaled around, their position and size in the image doesn't matter, and making changes to a single element only produces a small text diff, just like editing a single function in a source code file.
I am familiar with the SVG format; I've edited a few SVG images by hand (in a text editor; sometimes it's just easier). You're right that having multiple SVG pieces in a single file is not much different from having multiple functions in a source file, but in a way that is my point: it's not necessarily a big issue if you're a technical user, but for an average user it adds a complication they don't need or want. They'd typically want to dump whatever they can cook up in Inkscape in a well-defined location and be done with it (actually, so would I - just because I know how to handle multiple piece images in a single SVG file doesn't mean I want to).
Anyway, this is such a small implementation detail with negligible performance impact that I would say the best solution is to keep using whatever scheme you're already using.
I agree, there is no performance reason for using one solution or the other. But because of that that's not really the main concern here, and I think having all piece images in a single file will make it harder to create themes compared to having a single file per piece...
hgm wrote:
Joshua and I have spent a lot of time earlier this year to collect all kinds of different piece graphics, and package those in a universal way (including a makefile for doing the install). I just think it would be a big boon for the user if such packages could be interchanged between GUIs. Would it be possible to convert sets of individual SVGs into such amulti-image file through in install script?
Shouldn't be too hard to do. It's not quite "cat *.svg > joined.svg", but it shouldn't be much more complicated either.
