glue
glue copied to clipboard
Option to specify the output file names
As I understand it there is currently no way to define the names of the resulting files other then through the source dir. In most of my use cases this is cumbersome. I would appreciate the addition of an option to override this behavior. One option for both the style sheet and the sprite sheet would be sufficient.
May I kindly request you consider this feature for 0.9? I also found that #88 is for something similar.
Yes... but I'm not 100% sure about the api. --name would work for simple sprites... but what about sprites generated using --project? It would not make any sense combining --project --name=X.
Thought about using the --css --img --json option to not only mean the folder but also the filename... something like: glue source output --img=folder/sprite.png --css=folder/styles.css. This would be cool but introduces a boiler plate. What does glue source --img=a --css=b mean? generate two files a with the sprite and b with the css... or create two folders a including source.png and b including source.css? This solution is also incompatible with --project.
Using configuration files would be really easy... but was wondering if we can intruduce a command-line option.
Suggestions?
In a sense --project is the problem. Because in order to support it glue forces some assumptions about naming structure and other parameters. These assumptions currently prevent more fine-grained control. The convenience --project brings is not having to call glue multiple times, for what would be identical calls except for the source folder.
Also the existence of the two options --recursive and --project together is a bit confusing.
Ok, so I've been thinking about this a bit.
General API suggestion
- The second arg
outputis required and always sets the default output dir. --imgif present sets a different output dir for the sprite sheet.--cssif present sets a different output dir for the style sheet.--nameif present sets an output file name default (overriding the name taken from the source dir)--img-nameif present sets a different file name for the sprite sheet.--css-nameif present sets a different file name for the style sheet.
Now my recommendation: drop --project.
If you want to support this behavior in the future then in its place allow to use --recursive with an optional value, e.g. expand (or project).
--recursive=expandwould behave the same as--recursive --projectused to. It would create sprite bundles for each immediate child folders. In this case the output file names are still determined by the folder names (unless overridden by config files).--name,--img-nameand--css-namewould be ignored.
Of course you can keep --project as before and still implement the rest. But as I said, I think its a bit confusing.
Maybe this input has some value to you. Hopefully I didn't make up some totally incompatible stuff. :)
Has there been any new thoughts on this one?
I would like to take a stab at implementing some kind of option to name the files, but would like @jorgebastida to agree on the way it's implemented (to have chance of getting my pull request accepted :-)
I particulary need to name the scss file, as we depend on scss files prefixed with underscore in our project. Today I solve that by generating the scss file to a folder outside the sass project, and then copy/rename the file into the sass project folder. But to be able to generate the file directly to it's location with the correct name would be much better.
The way I would like to do that is by specifying the entire file path in the --scss command line option, like --scss=../sass-folder/some-subfolder/_sprites.scss
As a side note, beeing able to specifying the image file name would make it easier to refactor our project file structure, if needed, as the resulting filename would be independant of the source folder name.
To avoid the confusion about folder/filenames mentioned by @jorgebastida I suggest that if the value ends .scss (or .png for --img, .css for --css, .less for --less and so on) the value should be treated as a file name, otherwise it should be treated as a output path.
Also, I agree on @MarcDiethelm suggestion to drop the --project option as it's only complicate the understanding and flexibillity of the other command line options.