Open timriot opened 11 years ago
You would be a jerk for demanding that we make it possible to create folders with question marks in them! At least on Windows.
@DennisKehrig I've got to stay in character, right?
@DennisKehrig I demand fresh, hot cookies too!
:cookie:
@joelrbrandt your cookie is neither hot, nor fresh. (it's also kinda tiny, dude.)
You can have hot cookies. Since Hot Cookie has so far failed to give me cookies of noticeably increased temperature, I may need to attack them with a lighter first, but still.
Not really relevant to cookies or their temperature, but I think we have the Photoshop support in place. Node should track all the comps, and the 3 comp settings: visibility, appearance, and/or position. These are just 3 booleans per comp that say whether layers in that comp can have visibility, appearance (fx/blending), or position that differ from the active layer states. Look under "comps" in send doc info/imageChanged for this info. Node will also need to at least remember whether each comp layer matches the active layer for each of the 3 comp settings (or just track all the comp layer settings, which send doc info will give you). When you get an imageChanged event that would normally invalidate a thumbnail, you would need to see if that event also affects the comp's thumbnail. For example, a comp with visibility:true won't be affected by a "visible" layer event (because it tracks it's own visibility settings). For a comp with appearance:true, thumbs won't be affected by "fx" and "blending", and for comp position:true, "bounds" is preserved. You'll also need to pay attention to comps:[{captured:true}], meaning the comp layer settings have been synced to the active layer settings, and copy the "active" (non-comp) layer thumbnails to the comp's thumbs.
@DennisKehrig After you get pixel padding looking good. Let's take a look at this one, again.
@timriot That would be too much extra work for this sprint, methinks.
Notes from a conversation Tim I had a while ago, for reference: https://github.com/adobe-photoshop/generator-assets/wiki/Layer-Comps
Are you planning to export all layer-comps as folders?
I am trying to think of a use case, where i use Layercomps ti just quickly switch variations. Maybe to test them in an Edge Reflow Design. In this case, generating subfolders would be unnecessary.
Maybe adding a /
to the end of the LayerComs Name could be used as an indictor for creating a folder like in https://github.com/adobe-photoshop/generator-assets/issues/159
Howdy @mi1980ge! Adding a /
to the end of a layer comp name to indicate a tag was pretty much exactly what we were thinking.
Hi @timriot! Great! I adapted my table of examples on https://github.com/adobe-photoshop/generator-assets/issues/159 accordingly. Thanks!
@timriot We have a trello card in the 1-N backlog about this. We need to prioritize it. Currently, this is not slated for 15.0.
There is some discussion in #159 about syntax that would make this more useful
@joelrbrandt Let's chat. It was my hope that some portion of the work done for sub folders was applicable. Wishful thinking, probably.
Adding the DOM tag because this feature is dependent on a fleshed out model of layer comps in the new document model. The subfolder and default spec stuff will definitely be useful for this. The model is the remaining (non-trivial part).
Whats the status on this? Do you guys need help?
@joshspivey The good news is that support for generating pixmaps relative to a particular layer comp is now supported in Generator core as of adobe-photoshop/generator-core#235. The bad news is that we're a very small team and haven't had a chance to think much lately about exposing this in the image assets plugin. So we would LOVE help on this! If you submit a concrete proposal or a pull request, we will be delighted to consider it carefully, provide feedback, etc. In the meantime, we'll note your question as indication of increased interest in this feature and try to prioritize accordingly. Thanks for your interest!
@joshspivey I know that @jhatwich is currently working on a bit more layer comp goodness. If you're planning to actually start some work on this, the two of you should coordinate so that you don't step on each other's toes.
@jhatwich informs me that his PR should show up in the next week. I'm not entirely sure what it'll contain though -- he may just be adding APIs, not user-facing functionality.
@joshspivey You can try out the layer comp support I've been working on in the branch: https://github.com/adobe-photoshop/generator-assets/tree/jhatwich/layerComps
It works, but I was having trouble with honoring scaling parameters so layer comps always come out at 100%. I hope to have a chance to dig into that issue and get a PR up this week as @joelrbrandt mentioned.
Hi, also registering my need for this feature. I'm working toward a workflow for exporting multiple language versions of the same images (screenshots), with the language versions separated as layer comps.
While maybe more cumbersome — and a heck of a lot slower — Save for Web does what I need, as I can export images into named folders, although this requires manual control. Generator, as far as I can understand from reading about it, can only support currently visible layers, and not generate separate versions.
I would be more than happy to embrace Generator and leave Save for Web behind, though :-)
In spite of their current, crippled state, layer comps enjoy wide usage in the design community. It would be swell to have the ability to roll with the context, should those crafty designers be using layer comps.
Here's what I propose –
Given the following layer comps:
Output will be created in the following structure: