I was rewriting groups way but this conversation is making me rethink their purpose.
So what do you (and others) use groups for? Would you use groups if you had sub-models? Do you need groups to be nested? Would it be better to save selection sets instead? On Tue, Jan 7, 2014 at 11:36 AM, Joshua Delahunty <[email protected]>wrote: > For what it's worth, I used groups extensively when building the BI > mentioned here: > > > http://www.technicbricks.com/2011/08/building-instructions-for-nathanael.html > > So they definitely have their use, in the current incarnation (at least, > in the pre-Qt version of LeoCAD). > > -- joshua > > > ------------------------------ > *From:* Leonardo Zide <[email protected]> > *To:* Rodney Rushing <[email protected]> > *Cc:* "[email protected]" <[email protected]> > *Sent:* Tuesday, January 7, 2014 12:23 PM > > *Subject:* Re: Patch: Group Toolbar > > The original idea was just to make it easier to select pieces that are > always locked together (like a tire and wheel) and be a replacement for > sub-models. Maybe groups should have been selection sets instead and have > sub-models be used for complex groups. > > And that's why I don't like the current groups, it doesn't replace > sub-models and doesn't help with selection either because it tries to keep > all objects selected at the same time. > > I don't like changing things that aren't visible so you end up being > inconsistent one way or another. Maybe drawing a faded version of the > invisible pieces in the group is enough to show what's going on. > > On the code side groups are a terrible hack also. > > > > On Tue, Jan 7, 2014 at 8:27 AM, Rodney Rushing > <[email protected]>wrote: > > > Groups are something that I never finished implementing > > What was your original goal for groups? > > I don't think there is a problem with groups as they are (perhaps some > additional internal structure to make it more efficient to isolate groups > instead of scanning the whole piece list - but I also like the coherence of > having just one list.) All that seems to be lacking are (1) information to > make the user aware of how the operations are applied, and (2) consistency > in how operations are applied. > > If I knew render view operations would always apply to invisible pieces of > a group, and there was something to tip me off that there are invisible > pieces in my selection, I'd be satisfied. I do sometimes wish I could > position a sub-group. The group toolbar is a way to do the selection, but > the core logic that I didn't want to change is not aware of how to operate > at a specific group level. That seems like an easy change. > > Also, multiple views of the data are a big help in understanding your > model and manipulating pieces within the group irrespective of how they are > represented in some other view. > > - Rod > > > ________________________________ > > Date: Mon, 6 Jan 2014 17:04:24 -0800 > > Subject: Re: Patch: Group Toolbar > > From: [email protected] > > To: [email protected] > > CC: [email protected] > > > > I was on vacation and I'm just catching up with my emails. > > > > The reason why there are steps and frames is because LeoCAD used to > > have an animation mode where you could create simple animations using > > key frames and you could create animations and instructions in the same > > file. I've decided to remove it because it's not the main focus of the > > application (building instructions) so it adds to confusion and feature > > bloat. > > > > Groups are something that I never finished implementing, it's weird to > > have objects that are not visible be part of a group because it's not > > clear what should happen when you move the group. If you don't move the > > hidden objects the group will be wrong later but if you move them then > > you're moving something that's not visible. > > > > To be honest I think groups shouldn't exist in their current form, > > having a parenting system could be a better way solve the problem > > because pieces would always be relative to their parent so moving the > > parent automatically moves its children, even if they are hidden and > > more complicated groups that need multiple steps would be sub-models > > instead. I was actually implementing this system in my current work > > branch > > (svn.leocad.org/branches/model<http://svn.leocad.org/branches/model>). > > > > BTW, I usually develop new features in a separate branch so please post > > something if you plan on writing big features so we can try to avoid > > conflicts. > > > > > > > > _______________________________________________ > Leocad mailing list > [email protected] > https://list.gerf.org/listinfo/leocad > > >
_______________________________________________ Leocad mailing list [email protected] https://list.gerf.org/listinfo/leocad
