It makes sense to use the app icon if a dialog remains on top so you know what the window belongs to, but in the case of the tool dialogs they only show on the app screen so you should know what app your in. I just like clean lines.
[/quote]
That’s what I thought as I was looking at it… I plan on adding the ability to add other attributes to a group - such as line color, type and width - so you can place objects in a group with a given style if you will. Then when creating a new tool you would be able to select which group an object goes in, automatically styling the object without having to select the color, type, and width everytime. So the groups will do more than just setting an item visible or not. I may at some point redefine the “groups” as “layers” in keeping with the AAMA/DXF format. The groups tool as it stands acts more like layers than it does grouping items.
Moderator note: This thread picks up from post here - Susan
The only drawback I see to that idea is that one node may belong to numerous layers then, & that would be weird. Of course, most of my experience with layers is doodling around with rasters in the GIMP. So whatever terminology is standard in the pattern-drafting/vector community I’ll be happy to get used to.
I already addressed that… an object will only be able to added to 1 group at a time. Otherwise with all the permutations that can result with adding an object to different groups does get weird - and unpredictable as to it’s visibility. That “other” program who’s name shall not be said, has this problem. Again, the groups tool acts more like a layer than it does grouping objects in a vector program, where groups can be nested. Even then in a program like Corel Draw, you can’t group objects across groups, because when you click on an object it selects it’s whole group… which could then be nested. You can’t nest layers.
Currently this has not been implemented. What is currently implemented is being able to add objects to multiple groups. Not good. Do we want subgroups? Since the groups are like I’ve said more like (visibility) layers it really makes no sense. The groups are not like you would have in a CAD or vector program, where you group items and perform operations on them.
Bundle is not a good term to use… it has a different meaning in the garment industry. Family sounds too font related.
With that being said, what ever the name, I will have some much improved ways to create and manage groups / group items. The biggest change will be a different paradigm in adding items to a group. You will be able to add a new tool item to a group right in the tool dialog when you create the tool. Likewise it would be a simple click in the group combobox to change a tool item’s group. Currently you would have to delete groups and recreate them with the correct items. Pretty lame.
I was a getting a little frustrated a few weeks ago trying to sort out the various “layers” of a bodice block and trying to use the groups feature, unfairly trying to compare it to layer features found in other design applications. So, I started poking around to see if I could make a prototype based off of conversations that I’ve seen this in this thread and here about how it could be better. Hopefully this is ok - I didn’t see any branches actively working on this.
What do you think of this prototype?
A tree view seems like it would make sense - there’s a parent-child relationship between groups and points. The drag and drop feature is fairly intuitive and, if not, there’s a “move” option in a context menu. A single nested or multi-nested structure could be supported.
I imagine if someone moves/drags an object from one group to another, automatic styling would be supported with the implementation of this prototype.
Some background info… I’ve been working with the code since the split with Valentina before I started to support Seamly2D. I was working on my own fork as a sandbox… so I’m about 3 yrs ahead of Seamly2D. I’m slowing porting features I did in my fork to Seamly, while incorporating new ideas into those features along the way. That being said… I have a full fledge Group Manager worked out, but it may be in flux with the idea of semantic colors, line types., and line weight IE a pen “style”. While I haven’t dealt with the D&D features, it’s something that Qt supports, and something that I anticipate to incorporate down the road. IE… I want to walk before I run…
Here’s a video I did a while ago now sowing some of the group management and tool dilaogs
What I did is a whole new paradigm creating groups and adding, deleting, moving tools (points, curves, etc) to / from a group.
It includes several song recordings I did for a local TV show I use to produce showcasing local Buffalo bands.
I told myself that this was probably going to happen, but even if it did, it was at least a good starting exercise for getting back into C++ and exploring Qt class docs.
Thanks for sharing the video. I can’t wait until the new group improvements make it into master.
Side question: is there any way for me to tell if an issue already has an implementation in Seamly2d GitHub, like for this case?
Yup! I just replaced the current QTableWidget with a QTreeWidget, made some mods, and added drag and drop.
There’s a whole list of open issues on Github… and to be honest - I’d probably be the only one to be working on any given issue. I have a whole bunch of features to push, one of which will totally reorganize the tool directory file & name structure and look of the dialogs qui. This will pave the way for addressing the groups and some other tool features. Chance are if I created the (Github) issue… I’m working on the the feature.
In regards to the groups… what I worked out goes deeper than what you see… it’s tied into the pattern schema which is another whole ball of wax. Every time you add a new feature (or features) that are stored in the pattern file you have to deal with a new schema, and converting the old to the new - generally not fun - which is why I have a bunch of features to push. I like to group them together as it’s easier to limit the number of schema changes. It also means every time you add new schemas it takes that much longer to load older patterns as loading a pattern has to convert one pattern ver to the next until you reach the current.
Anyhow, if you look at open issues on Github they may be assigned to someone…like here’s one assigned to me by susan. Which based on the date I probably should take a look this one again. LOL
[/quote]
