Feature: Allow Operation tools to work on defined Groups.

[sconklin]

In the Operations tool group, there is an option to define a group.

It would be helpful to be able to define a group, then select an Operation tool (eg Rotate, Flip, Move), and select the group to perform the operation on.

[sconklin]

The user should be able to choose an Operation tool (like Move), then select a group from the Group list, then press enter to open the tool dialog.

[slspencer]

First improve how Groups are created, deleted, updated, and selected. Then enable Operations tools to select the group.

[DSCaskey]

In the Operations tool group, there is an option to define a group.

It would be helpful to be able to define a group, then select an Operation tool (eg Rotate, Flip, Move), and select the group to >perform the operation on.

Don't think this is feasible the way the "groups" currently work. The groups are not a tool in the sense that other tools are... the groups are simply created on the fly from the dom doc and don't deal with the data container and GObjects like other tools. Basically, the groups are a glorified list to toggle the visibility of objects on / off.

That being said... we already have the ability to do this, albeit the order is reversed... we select tool, then objects rather than select objects then tool. The current problem that exists though is the fact the source objects for the op's tools can NOT be edited ie: added or deleted. - which means if you forgot something or need to delete an object, you have to recreate the tool. The destination objects also lack some of the source attribute properties, such as (separate) color and line type.

[slspencer]

Looking for ways to create some efficiencies for Operations tools.

Since the Groups are "glorified lists" we could select the Operation then click on a Group in the GroupManager in addition to clicking on objects in the Canvas. This would add the Group's objects to the Operation but wouldn't add the Group. If the Group gets deleted the Operation still functions.

[stefan123t]

I am trying to wrap my head around the DOM model structure. I looked into the Seamly pattern files to see the XML structure which is being used for storage.

I found the best view still is the History with the details of what type of objects you have created in sequence. When I hide a point / other object from the Draft view it may not be immediately clear how to make it visible again. Here these 'glorified lists' of objects could come into play.

I still struggle to see how you would structure a list of all objects in the side bar, comparable to the "Layers and Objects" sidebar in Inkscape, i.e. as a tree. Especially given that currently a single object can be in multiple groups. I wonder if this is a necessity ?

Regarding the target of operations the current workflow is to first select the action / operation and then the objects to execute this operation on. I compare this to the "reverse polish notation" for arithmetic terms, were you first give the operation and then the operands. Most UIs and apps are usually built the other way around, you first select the operands / points, lines & curves and then you select the operation from the toolbar.

To select multiple objects is possible in Seamly2D using the Ctrl+Mouse (more common would be Shift+Mouse) or using the common rectangular drag mouse gesture. If you then right click on any of the selected objects and select +Add Group Object > Group1 it will only add the specific object to the group and not the complete "list of objects" previously selected. Also note that it is currently only possible to add objects to an pre-existing group, i.e. you always have to first add the group in the group manager and then perform the above actions. This could be fixed by adding a New Group entry into the context menu.