This is proposal for a possible feature, interaction with sub objects of grouped objects.
Actually fabricjs can just detects click over them.
We need to define:
1) actions available with grouped objects
2) method of activating this objects
3) having both internal and normalized corner coords
4) .....
Discuss Pro and Cons of keeping this in the library or keeping at application level
I throw some example:
moving object inside a group without ungrouping.
problems: relative coordinates and updating group dimensions.
Nested groups, full support of basic functionalities we have now
That is a long term feature.
@kangax @kienz @inssein @samuelhorwitz
Here is my resubmitted pull request #3014
This supports double click drill down to manipulate objects nested in groups.
The main shortcoming is how already grouped objects being shift selected break. Also, how will we handle multiple selection of objects at different group layers?
I got the double click to select thing from my UX coworker analyzing Sketch (an application for drawing).
As for application level versus library level, I strongly recommend library level. I have worked happily with Fabric for 2 years now on a project. I have thousands of lines of application code and thousands of lines of Fabric subclassing code. This is the first thing that I couldn't elegantly add to Fabric via subclassing.
The generally accepted application level solution right now on Stackoverflow, etc, is to degroup, manipulate and regroup objects. This works but only on very small scale applications. We depend on the internal objects array as a model for a lot of reasons and changing this representation, even intermediately, causes a lot of issues. Furthermore, it's not a nice fix because it involves changing your model to work with your interface.
In regards to the User Experience of double-clicking as an accessor for nested objects/groups:
This needs to be library level, rather than API driven. Out of the box, there would be no other way to use grouping without every application implementing double-click handlers. Since this is already in FabrisJS for iText, abstracting it and using it as a service for both features just makes sense.
I do think too, that a better handling of groups of objects would be very helpful. But I’m not sure, if subnesting is the best way to go. It might become difficult, to handle objects at the 3rd or 4th level of nesting – within the program code and for the user of the application.
Luckily there exists the concept of layers and it is used in most drawing applications (e. g. Photoshop, Illustrator, Corel Draw, Sketch, CAD programs, even Gimp and Photoshop Elements).
There is already an issue on it (#3000).
I recommend to have a look, especially at the linked videos.
I see what you mean about layers, I'm sympathetic to a lot of your points as I have implemented a lot of layer functionality at an application level (ignoring the nesting parts). The next step for me was to figure out how to have selectable nested objects of arbitrary depth which is necessary for my application, and I realized that my attempts at the application level code were not cutting it.
As for users getting confused, I admit I haven't thought about that too much because my application includes a "layers" panel which clearly lays out the nesting of all the objects. But yes, Fabric as it ships will obviously not include this. However, Fabric supports arbitrary group nesting either way and I still believe the ability to select sub-objects is desirable.
I'm also including a Codepen link for people who want to check out my work so far but don't feel like cloning and building and writing a test page. I'll try and keep the build updated. This shows nesting up to 3 layers deep. I think that even without a layers panel, the interactivity is intuitive. http://codepen.io/anon/pen/rLNaxW?editors=1010
Hey guys, I just want to let everyone know that I've reached a pretty good place with regards to this pull request. It currently works as intended for what I needed my fork of Fabric to do.
The Codepen link above has been updated. It supports selection of objects that are already grouped.
Does anyone have any thoughts on this?
I've opened a new PR with a rebased from 1.6.3 version of my branch here: #3093
The Codepen I have set up at http://codepen.io/anon/pen/rLNaxW?editors=1010 is up to date with a new second interface for programmatically selecting objects.
@samuelhorwitz that is using old version(1.6.x).
Do you have example for version 3.x ?
Unfortunately, I don't. The project I was working on at work that I was developing with Fabric for was shelved indefinitely and I haven't kept up to date with Fabric since. If they are on version 3, is this stuff maybe not already present in the library now?
version 3 is version 2 with better node supports.
Unfortunately, I don't. The project I was working on at work that I was developing with Fabric for was shelved indefinitely and I haven't kept up to date with Fabric since. If they are on version 3, is this stuff maybe not already present in the library now?
Thank for your answer, I try any example group with version 2x and 3.x it not working well.
Most helpful comment
Here is my resubmitted pull request #3014
This supports double click drill down to manipulate objects nested in groups.
The main shortcoming is how already grouped objects being shift selected break. Also, how will we handle multiple selection of objects at different group layers?
I got the double click to select thing from my UX coworker analyzing Sketch (an application for drawing).
As for application level versus library level, I strongly recommend library level. I have worked happily with Fabric for 2 years now on a project. I have thousands of lines of application code and thousands of lines of Fabric subclassing code. This is the first thing that I couldn't elegantly add to Fabric via subclassing.
The generally accepted application level solution right now on Stackoverflow, etc, is to degroup, manipulate and regroup objects. This works but only on very small scale applications. We depend on the internal objects array as a model for a lot of reasons and changing this representation, even intermediately, causes a lot of issues. Furthermore, it's not a nice fix because it involves changing your model to work with your interface.