Applying styled group ( accumulated )
-
Notice: Accumulated into mega-topic.
If I have two almost identical groups, the only difference being, for example, the colors of rectangles, would it be possible to apply the first one as a nested style on the second group? I'm experimenting with object styles, but it doesn't really work.
-
@Nils Just to clarify:
- two similar object hierarchies.
- create a "grouped" object style.
- style the objects in the second with styles from objects of the first.
- by matching objects based on the location in the object tree.
If so, I can add this as a feature request. I will have to think about how this would work in the UI.
-
@vectoradmin That's exactly right. This would basically be one more important step in overcoming the limitations of symbols. Would be extremely nice to have this.
While this isn't yet available, does any similar workaround occur to you?
EDIT:
Also, the way I encountered this was by searching for a way to define a transparency style, that I could apply separate from color style. Is this possible?
UPDATE:
Figured out how to do the EDIT. It turns out that object style and color style can be combined, I assumed this would break.
-
@Nils The only way to locally alter something inside a symbol, is to use "styles" in the original, and then override this style. For example:
- a symbol is a group containing multiple objects
- set the shape of one of those objects from a style.
- that shape can be redefined using overrides in a symbol instance.
The above case would not work even with "hierarchical" object styles, as these would not affect the shape.
The way I see it, the only drawback of using symbols is that they require a more organized workflow.I think the opacity (or mask) styling is missing (only mask content can be linked now). I add this to the backlog.
-
@vectoradmin Thanks for adding the opacity style.
The way I see it, the only drawback of using symbols is that they require a more organized workflow.
I disagree very much.
If the same style is used multiple times in a symbol, you can't choose which use to override. It's all or nothing. This is a huge pita with nested symbol hierarchies.
To this day I haven't quite understood why symbols in virtually every vector drawing software are sealed in this way. Why not make them a better analogy to objects in programming languages? :
( Building Symbol ).( Window Symbols )[2].( Glass Sheet Symbol ).color = "red"
What's the technical limitation here?
Example use case: Symbol "building" contains multiple instances of symbol "window". Wanna change the glass color style of one instance of the "window" symbol, but keep the other? Impossible with nested symbols. Instead you'd have to create a separate "window_alt" symbol, that uses a different color and use it for the override. This isn't flexible at all.
The above case would not work even with "hierarchical" object styles, as these would not affect the shape.
Well, it wouldn't work if you wanted an automatic way, but you definitely could build up a styled group ( selecting the styles manually ), copy that object around like you would instantiate symbols and then do your shape override. What's not working here?
I agree with you about memory usage with this approach, but I doubt this would become a problem on a non-ancient computer before reaching a truly gigantic file size..
-
@Nils said in Applying styled group:
If the same style is used multiple times in a symbol, you can't choose which use to override. It's all or nothing. This is a huge pita with nested symbol hierarchies.
This is a good point. I think what is needed then a more pointed style override inside a symbol.
To this day I haven't quite understood why symbols in virtually every vector drawing software are sealed in this way.
I think the reason why many vector apps do this is efficiency in size. You can have hundreds of instances of a complex symbol, without affecting much the file size (or memory use).
Yes, clones can solve this issue somewhat. I think what we need here is the "best of both worlds" solution.
-
@vectoradmin Nice to hear that you agree.
Couldn't you provide a checkbox option on a symbol, like "Modify", which would cause the instance leaf that receives the graph pointer from the definition to copy the configuration. In the UI, you could then change the Overrides panel in such a way that you could perform overrides that are more analagous to object property accessors from programming languages. This way, efficient referencing would be the default, while "power" users could still enable some instancs to be copies and modify them.
Feel free to remind me of technical misunderstandings here. I'm tapping in the dark after all..
-
@Nils I will think of a way to do this: for example allowing selection to enter into symbol (explicitly blocked now), could select an object inside, and style overrides could be applied to that object only, without "unrolling" the whole thing.
-
@vectoradmin I see. Looking forward to it.
-
@vectoradmin Any idea how long this would take to ship? Probably not next build right?
-
@Nils The next build will have only bug fixes still (but it is planned for Monday).
Then (if all goes well) comes a longer (feature) sprint, with the highest priority feature list, and this is included. So my estimate, at most 3 weeks starting from next Monday.
-
@vectoradmin said in Applying styled group:
The next build will have only bug fixes still (but it is planned for Monday).
Would you consider putting another bug fix build before the feature build if some things won't work yet? It would be great to have the most important things working well, especially considering clones, since they can be used until the more elaborate symbol overrides are implemented, but are quite buggy atm. I'm gonna post some bugs again, today.
-
@Nils yes, of course, if there are bugs reported (but depending on severity), and an be fixed, than an earlier build is always possible.
About clone: besides the refresh issue, was there anything else?
-
@vectoradmin Yes, several other things, if I remember correctly. I'll make some detailed report with gifs in the next hour or so.. Would it be better to include everything ( if there are several things, I can't remember perfectly ) in one topic or separate into multiple smaller bugs?
-
@Nils Include everything in one topic about cloning issues.
-
@vectoradmin Okay.
For the future: Should bugs relating to core topics like Clones, Symbols, Roles, etc. be "accumulated" over time into one topic, that is adding on to an existing topic.
If yes, should I do that for the previously posted symbol issues aswell or do you have a good oversight of that?
-
@Nils said in Applying styled group:
@vectoradmin Okay.
For the future: Should bugs relating to core topics like Clones, Symbols, Roles, etc. be "accumulated" over time into one topic, that is adding on to an existing topic.
One thread may contain multiple bugs, but if a new set of bugs is discovered (same for features) it is better to create a new thread.
The reason is that these might end up as different backlog items, and in this way it is easier for me to link to the post.If yes, should I do that for the previously posted symbol issues aswell or do you have a good oversight of that?
Same here, if there are new issues other than the existing ones, then a new thread is better. But if there are further observations, cases or ways to replicate on existing bugs, then keep posting on the related thread.
EDIT: the cloning thread for example can continue with cloning bugs, until they are fixed. Then a new thread is created.
-
@vectoradmin I see. From your description it seems a little hard to determine the scope of separation of concerns here. That is - what is a "new set of bugs"?
Or should I not overvalue that and just apply separation as I see fit ( everything clone related into one, everything symbol related into another, etc. .. )?
-
@Nils said in Applying styled group:
Or should I not overvalue that and just apply separation as I see fit ( everything clone related into one, everything symbol related into another, etc. .. )?
Yes.
