Author Topic: Nested group fix  (Read 9686 times)

Dr PR

  • Hero Member
  • *****
  • Posts: 5440
Nested group fix
« on: June 26, 2012, 11:45:27 PM »
Nested groups are screwed up because a hidden container is created on the active layer when the group is created, even if there are no parts of the group on the active layer. This creates a hidden container on a layer that has no parts of the group in it. This stray invisible container can cause several problems.

The problem is not the hidden container. When the container is created it should be placed on a layer that actually contains drawing objects. Which layer is irrelevant since all of the objects and the container act as a single object when grouped. When the group is exploded the hidden container ceases to exist.

I think this simple modification would eliminate all of the problems with nested groups, and I can think of no complications it would add. Then nested groups would work correctly and finally be useable.

Phil


DesignCAD user since 1987

paulerens

  • Hero Member
  • *****
  • Posts: 915
Re: Nested group fix
« Reply #1 on: July 02, 2012, 02:59:42 PM »
Phil,
The first question we must ask "why is a  Nested group  an Entity (34) and no an number?
All other provisions of state of an "object" =( Entity) are only numbers.
Type-layer-group-solid-color etc.
Why is a group defined by a number and a nested group by the use of one or more entities?
That is the question.
Paul.

prl

  • Hero Member
  • *****
  • Posts: 3389
  • A Bézier Extrusion
Re: Nested group fix
« Reply #2 on: July 03, 2012, 07:46:55 AM »
Why is a group defined by a number and a nested group by the use of one or more entities?
That is the question.

Just guessing - old coding methods that were focused on saving memory space versus new object style programming methods.

Back in the old days, integers used less space then strings.  So rather than each DesignCAD entity having numerous string fields for layers, solids ids, group names, etc; DesignCAD used index numbers that referred to a string look-up table.  Great for back then, terrible for now.  The entity 34 is probably some sort of hybrid text container holding entity string ids, not index numbers since they constantly change.
« Last Edit: July 03, 2012, 07:59:50 AM by prl »

paulerens

  • Hero Member
  • *****
  • Posts: 915
Re: Nested group fix
« Reply #3 on: July 04, 2012, 02:20:38 PM »
prl,
I guess...  you're right. ;D
« Last Edit: July 04, 2012, 02:22:47 PM by paulerens »

DrollTroll

  • Kindly Curmudgeon
  • Administrator
  • *****
  • Posts: 4152
Re: Nested group fix
« Reply #4 on: July 05, 2012, 11:16:58 AM »
Simple, non-nested groups contained a group id -- all entities with the same group id were in the same group.

That won't work for nested groups -- since each entity only contains one id, how do you represent the fact that it may be contained in a hierarchy of groups? You can't with a simple ID. So, we introduced entity 34 -- a "group container". The group container has a number indicating which group id it "contains". It also has a parent group id number, which indicates which group, if any, contains the group this container is managing. This allows a group to contain individual entities, other groups, or a combination of groups and previously ungroupd objects.
25 years with DesignCAD

Rob S

  • Hero Member
  • *****
  • Posts: 4332
    • Construction Estimating Program for General Contractors
Re: Nested group fix
« Reply #5 on: July 05, 2012, 12:08:51 PM »
So, to satisfy all different users, could there conceivably be some options for how entity 34 is created and displayed

[ ] Create nested groups on current layer

[ ] Create nested groups on same layer as first entity in group

[ ] Allow hiding of groups by turning off host layer

[ ] etc

User since Pro-design

prl

  • Hero Member
  • *****
  • Posts: 3389
  • A Bézier Extrusion
Re: Nested group fix
« Reply #6 on: July 05, 2012, 12:46:38 PM »
[ ] Create nested groups on current layer
[ ] Create nested groups on same layer as first entity in group
[ ] Allow hiding of groups by turning off host layer

Well my fix would be that nested groups does only one thing "nested groups".  Not tied to layers or anything else. 

For visibility, all collective entities such as groups, blocks, solids would have a separate property (visible, yes/no) through info box.  Then to keep track of what is and isn't hidden, provide a component browser or some way to invert the visible/invisible (say all visible items become halftone, and invisible items become fully visible).  In this "behind the curtain" mode you can select the invisible entities and via the infobox, turn them back on.

My two euros.

Lar

  • Hero Member
  • *****
  • Posts: 2548
Re: Nested group fix
« Reply #7 on: July 05, 2012, 07:48:01 PM »
What about the flip side: instead of getting rid of the invisible container we make the container visible? We have a visible entity that we can click on to select. A simple example (and one I don't really like but just for the sake of discussion) would be a line running between all the entities of a nested group. You click on the line and the nest gets selected. If you click on an entity/group/solid in the nest only that thing gets selected instead of the whole nest. The lines would designate the different depths within the nest so clicking a particular line would only select from that level down and you would be able to rearrange lines to change levels. This would be the equivalent of a hierarchical text list, but on screen instead of in a dialog box.

Like I said, I don't really like the lines idea because that can really clutter up the screen.

It may be more realistic to have a 'nested group dialog box' (that can stay open like the info box) that lists all of the nested groups and their hierarchy, as demonstrated below:
    + Nest 1 (re-nameable, shows what layer the container is on and its status)
        +|_ Level 1
               +|_ Level 2
                     +|_ Level 3, etc...

...Where ever you click on the list selects that level of entities and everything below it. To fold up a level (in the dialog) you would click on the +. The hierarchy would not attempt to show what entities each level contains, it just shows the number of levels and allows you to select a level and what's below it. Also, it would not attempt to control visibility. Clicking on an entity on screen would only select that entity/group/solid but it's level would highlight in the dialog so you know to which nest it belongs. Also it's parent would highlight lighter so if the nest is folded you know which nest it belongs to.

Whether entities can be a part of more than one nest is up for debate.

Lar

Dr PR

  • Hero Member
  • *****
  • Posts: 5440
Re: Nested group fix
« Reply #8 on: July 05, 2012, 10:38:18 PM »
Lar,

I think I suggested something similar a while back. It would be a part of the Info Box dialog for groups. However, and independent group viewer dialog would be just as good.

It would be great if you could use the heirarchy to partially disassemble the nested groups. For example, select a single level and explode that nest. All objects in the selected level would become ungrouped, and the group (or nested groups) below that level would become an independent group (or nested group). All groups above the selected level would remain in a nested group with all other groups above. Like this:

Original configuration

Nested Group 4
  Objects
  Groups
  Nested Group 3
    Objects
    Groups
    Nested Group 2
      Objects
      Groups
      Nested Group 1
        Objects
        Groups

Select Nested Group 2 and explode it:

Nested Group 4
  Objects
  Groups
  Nested Group 3
    Objects
    Groups

Objects
Groups

Nested Group 1
   Objects
   Groups

This would break the chain leaving two nested groups 4&3 and 1. The objects in Nested Group 2 would be come independent.

If you selected several levels and exploded them all of the objects in the selected nests would become independent.

For this to work all selected objects would have to be highlighted in the work windows so we could tell what we were doing.

Phil
DesignCAD user since 1987

paulerens

  • Hero Member
  • *****
  • Posts: 915
Re: Nested group fix
« Reply #9 on: July 06, 2012, 01:38:04 AM »
Lar and Phil,
With your suggestions I can live!
This would make (nested Groups) be useful and usable.

Paul.

Lar

  • Hero Member
  • *****
  • Posts: 2548
Re: Nested group fix
« Reply #10 on: July 06, 2012, 06:11:47 AM »
Phil,

I would suggest the dialog only show nested groups, so if you explode a level it disappears off the list. Maybe you would be able to drag a level (and its children) downward so it detaches and becomes its own nested group (the level numbers would adjust automatically). If you then detach the new level2 from level1, level1 disappears since it is not nested anymore (and lev2 becomes lev1 in the nest).  In your example the numbering runs from higher to lower, which is in line with how nests work now, in its rigid fashion. In my example the setup would be flexible so you can move levels (with its children) up and down the list, so for sanity's sake the numbering runs down the list from lower to higher.

As always, this or any concept would need a lot of thought before before implementation.

Lar
« Last Edit: July 06, 2012, 06:14:46 AM by Lar »

Dr PR

  • Hero Member
  • *****
  • Posts: 5440
Re: Nested group fix
« Reply #11 on: July 06, 2012, 09:35:00 AM »
Lar,

I agree. Originally I just wanted to be able to select a group, open the Info Box, and get an idea how complex it's structure was.

Being able to edit the structure is a new, and not well thought-out idea. I can live without that.

However, what I envisioned for "structural" information was something like what we get with the Drawing Info tool - a list of the types and numbers of objects in a group.

Phil
DesignCAD user since 1987

prl

  • Hero Member
  • *****
  • Posts: 3389
  • A Bézier Extrusion
Re: Nested group fix
« Reply #12 on: July 06, 2012, 10:36:08 AM »
As always, this or any concept would need a lot of thought before before implementation.

"We" aren't consulted about such things.  They just happen and then become obstacles.  I would prefer an "initial feedback" approach to new features. My DesignCAD development outline would be :  1.) do no harm,  2.) whatever you do, cover all angles and work 100%, 3.) keep it sweet and simple, and 4.) provide basiccad and ole equivalents.

Lar

  • Hero Member
  • *****
  • Posts: 2548
Re: Nested group fix
« Reply #13 on: July 06, 2012, 12:02:58 PM »
Prl, hopefully the beta testers may have some input. Still, if the wider community thrash it out the developers would have a sense of what the users would go for.

Lar

Rob S

  • Hero Member
  • *****
  • Posts: 4332
    • Construction Estimating Program for General Contractors
Re: Nested group fix
« Reply #14 on: July 06, 2012, 02:19:39 PM »
As always, this or any concept would need a lot of thought before before implementation.

"We" aren't consulted about such things.  They just happen and then become obstacles.  I would prefer an "initial feedback" approach to new features. My DesignCAD development outline would be :  1.) do no harm,  2.) whatever you do, cover all angles and work 100%, 3.) keep it sweet and simple, and 4.) provide basiccad and ole equivalents.

I'm afraid meeting all these requirements given the wide variety of users, systems, and hardware, would bring all development to a screeching halt.

It sometimes takes weeks to discover how one tiny change has impacted some unrelated other thing no one thought of.

How about:

1) Attempt to minimize impact on existing functions - ie in the case of the layers dialog they provided both until the new one has been tried by all.

2) To make sure things work for all concerned, provide wide beta releases of upcoming versions to all registered users that the adventurous can work with, and the cautious can avoid.  In effect, the current 22.0 should be considered a wide beta, and hopefully the upcoming 22.1 the release.

3) Try to balance all possible options anyone may want with keeping it simple - I think DCAD does well at this.

4) Advanced parameters available to basic-cad users for the more involved options might be good in some cases

5) Initial feedback is often very inconsistent, so retain only superhuman developers who can interpret a thread such as this, and figure out from it what we (all) really want!!!!   :)
User since Pro-design