The only “logical conflicts” will be when trying to remember which one you worked on last.
If the 2nd folder is only a backup folder where you save a copy of the pattern, this shouldn’t be a problem since you will only be copying the working file over the one in the backup folder after you’ve worked on it for security reasons. If you do hit a glitch, you can open the backup file and save it over the original to return the original file to the previous state.
If this is not the case, then I suggest that you change or add something to the name so that you can differentiate between the different files that you are working on to prevent mistakes.
Ja, dass mache ich sowieso. Mir ging es nur um die Struktur der Gruppen.
Ganz aktuell habe ich ein zweiteiligen Reverskragen gebaut. Ich habe dieser Gruppe eine Farbe gegeben. Auf dem Weg dahin musste ich ganz viele Gruppen dazu anlegen. Gruppe Kragen mit ganz vielen einzelnen Gruppen Konstruktion, weil ich viele Objekte nacheinander bewegen musste. Um nicht im Chaos zu landen habe ich ganz viele Gruppen für die Konstruktion angelegt. Das gleiche musste ich auch mit dem Steg machen. Zum Schluss hatte ich ganz viele Gruppen in dieser Farbe. Hätte ich die Möglichkeit gehabt Untergruppen zu bilden wären sie geblieben. Da es nicht geht habe ich zum Schluss alle einzeln Gruppen die die Konstruktion Kragen und Steg betrafen gelöscht und in zwei Gruppen gebündelt. Vorher war jeder einzelnen Schritt schon aufgeräumt in einer eigenen Gruppe.
Inkscape has both groups & layers. Of course, I mostly use groups, & avoid layers, because layers give too much separation between objects.
I am not one who has taken advantage of Seamly’s Venn groupings. I’ve barely used groups at all. But I have many times wished that I could use Venn groupings on my (physical) objects.
Not the same thing. In your example there are physically 2 files… one in each folder. In this case there is only ONE graphic object. It can’t have 2 (or more) states at the same time.
Precisely. It’s a spin on the Schrodinger’s cat senario… object could be red, could be blue could be green… but can’t be red, blue, and green at the same time. We have to make an observation. i.e. Assign the object 1 color.
My idea would to replace the group combobox and use a table instead… along these lines:
Where for ex: You could check to place the new tool object in the Skirt Back and Skirt Front groups. and the ByGroup color would be assigned Skirt Front’s color.
Could keep the tool dialog space use to a minimum by showing the ByGroup in use (like the combobox did), and the edit button would open the full group table as another dialog.
That’s probably the best way to desribe using multiple groups. Just throwing a crazy idea out there… just like a Venn diagram has a different color for different overlapping areas… what if we combine the colors of the overlapping visible groups into a new ByGroup color?
For ex: Given Group A is Blue, Group B is Red… If only Group A is visible the color is Blue, If only Group B is visible the color is Red… if both groups are visible the color is Purple. Of course if you have 5 groups and they are all visible the color is mud brown.
We kind of already have layers… each draft block is analgous to the typical layer. It’s just that in Seamly only 1 draftblock is active at time, and in Seamly objects can not be moved from 1 block (layer) to another like you can in a typical CAD, Vector, or paint program. If we could it would be like having a 3 dimentional Etch-A-Sketch.
Ein bisschen Arbeit muss ja auch noch bei dem Anwender sein. Es dauert halt seine Zeit, bis man sich mit dem arrangiert hat, was gegeben ist. Anfangs macht man auch Fehler, dass passiert in Inscape, Seamly Pfotoshop, Exel, Word usw.
Ich denke jeder muss für sich ein System festlegen mit dem er sich gut arrangieren und arbeiten kann. Ich weiß garnicht wie lange ich schon dabei bin. Ich habe viel Fehler gemacht und musste so einiges doppelt arbeiten. Aber im Endeffekt hat mir das Programm, auch Dank @Douglas und @Grace und den vielen anderen Personen hier im Forum, die Arbeit sehr erleichtert. Und der Austausch hier ist wunderbar.
Just a note on groups & layers from a tech perspective, as this will affect how well we can implement both groups & layers.
In SVG, groups & layers are the same thing and implemented with the <g> element tag. The definition and visibility of “layers” as separate from “groups” is implemented by each software platform (IIlustrator, Inkscape, etc)
The good news is that in SVG, we can add custom attributes to groups, like data-layer=1 and data-layer-visibility=0 (custom attributes begin with “data-”).
This way multiple groups can be in a layer, whose visibility can be switched on and off.
I’m hopeful that eventually we’ll be able to perform operations (move, rotate, etc) on groups, which could then be extended to layers.
On the issue of group styling, we will need a order of groups, just like we would need an order of layers, so that we know the hierarchy rules to apply the styling.
In SVG, the styling of the individual object overrides the styling of the group.
To apply group styling to group members, as a UI suggestion, the user could check a box to remove an object’s styling so it can inherit styling from its group. Implementing ‘Undo\Redo’ for this could mean defining a styling queue for each object where we push/pop the styling attribute. Lots of overhead.
