Feature request : GUI-level group [$75 awarded]

[zozorg]

When a complex transformation involving several layers is repeated over and over, the layers panel tends to become painful to browse. It's not possible to group the layers since a group layer limits the scope.
A GUI-level group would merely group layers at the GUI level, not limiting their scope.
For example, if a GUI-level group contains a Translate layer and a Stretch layer, it acts as a translate+stretch layer.

---

The $75 bounty on this issue has been claimed at Bountysource.

[zozorg]

Posted a $60 bounty

[morevnaproject]

Hello @zozorg! Thank you very much for giving extensive support to Synfig on Bountysource! Right now I am looking for possibility to extend our team with one more hired developer. I already found one candidate with a powerful skills. Bringing him to the team will take some time, but the support you provided with bounties makes this task easier for me. Thank you!

[zozorg]

Awesome :-) How much does it cost to hire a developer?

[morevnaproject]

The candidate I am talking about needs minimum $1k per month. But for first month I can hire him for $700 (because in first month he needs to learn how everything works in the project and thus he will be less effective comparing to consequent months). With your contributions I can reduce the amount of first month to $500-$400, since he can fulfill the remaining amount through bounties. I am considering to get this amount by setting up a dedicated Patreon page.

But first I have to release version 1.3.5. Tomorrow I will finish building binary packages and will start writing release notes (maybe I will even get some demonstration video about new features). ^__^

[caryoscelus]

@zozorg, you can currently use "sets" feature for logical layer grouping, though that's quite far from what you're proposing.

Another possible non-radical solution would be to add layer filtering (by name/type/"sets"/etc). As far as i can tell, that might be easier than to do than your "GUI-level group" (at least it was easy to implement this in Qt); it's also more flexible, but on the other hand less permanent (i.e. you need to change filter line each time you need to get to required layer).

As for your proposal, personally i find it too complicated to implement with current code base to be a high priority. If current synfig status is "maintaining mode with patching bugs and minor improvements", it's too radical solution (for one, it breaks forward compatibility, unless it is somehow made optional; for another, it requires changes in multiple parts of code). On the other hand, if we want real development, i think to implement this effectively we'd need rewrite large portions of code. But then i might be biased about this since i mostly abandoned synfig for my from scratch project.

While i was writing this, i came across another idea: combine current "sets" feature with layer tree. E.g. adjacent layers in the same set are visually grouped. This would reduce necessary code changes to layer tree model. This variant of implementing your FR might actually work, i think.

[zozorg]

@caryoscelus
I didn't think about forward compatibility. But I can see it's possible to add a XML tag to a layer that synfig will simply ignore.
<layer type="circle" active="true" exclude_from_rendering="false" IGNORED_TAG="BLAH BLAH" version="0.2" desc="Circle">
... simple version :
A layer can be marked as "hidden", adjacent hidden layers are grouped ( so not totally hidden ^^ )
... more complex version
A layer can be marked with a "gui_group_ID", adjacent layers of same gui_group_ID are grouped ( GUI groups can't nest. I'm OK with that )
... even more complex:
gui_group_id is some kind of "path" to allow GUI group nesting.

Older versions will simply ignore this tag.
Does this sound feasible?

[caryoscelus]

Well, yeah, this

A layer can be marked with a "gui_group_ID", adjacent layers of same gui_group_ID are grouped ( GUI groups can't nest. I'm OK with that )

is pretty much what i suggested in the latter part of my post (except that sets are actually already exist ^_^).

It's just that your initial suggestion was worded in a way that suggested this to be implemented as layer.

[caryoscelus]

Interestingly enough, i just discovered (by reading code) that sets can be nested. So basically if you don't mind extra work of tagging everything, it's possible to recreate whatever tree structure you desire.

Example: sets-recreate-groups.sif.txt (remove .txt extension to open in synfig)

[zozorg]

But I don't always want layers of the same set to group ^^

[caryoscelus]

I'm just showing a way how something like this can work now.

As for FR implementation, adding new tags would surely add some work, but i suppose the most of it would still be with tree model itself anyway. The problem is (as usual with synfig) is that code there is not very good and so there's usual dilemma: rewrite that piece or try to understand and then patch it up.

[caryoscelus]

So yeah, might work.

[zozorg]

Oh, "REcreate" a tree structure, got it ^^

[zozorg]

@morevnaproject
How can I message you privately?

[morevnaproject]

@zozorg Please drop me a message via this form - https://morevnaproject.org/about/contact/