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
