The Philosophy of Classes

[Mbuck]

Undoubtedly one of the most powerful and I would suggest one of the most unique software concepts extant within Vectorworks is the ?class?. At first a difficult concept to grasp due to the fact that not many other CAD packages have such software constructs, whereby an object visibility is controlled both by layers and classes settings. Although, an immensely powerful concept, I would suggest that this feature would be the most off-putting feature VW presents to new users. The often heard complaint is - why are whole objects, and in some cases, parts of my objects disappearing on the screen? Another; why is this object on this layer and not on the other? Most AutoCad switchers would be very perplexed when they encountered such situations. These experiences are frustrating and on the surface counter intuitive and therefore are at odds with NNA stated aim to make VW operation and user interface simple, clean, and intuitive. NNA philosophically, I would suggest is not much different to Apple?s who as a company espouses a metaphor which states that in no case should the primary user interface or tool be a reflection of the true complexity of the underlying implementation. Yet I would suggest the class concept breaks with this tradition. I am not saying, however, that class concept is flawed, but rather that the power of this concept needs to refocused towards what users are trying to achieve when using classes. It is important not to overwhelm the beginning user with too much detail; yet, classes seem to do just that. Valuable insights can be gained by simply watching other people attempt to use the class feature, when I did this I realised that classes where somehow missing something, and I now think I know what that ?something? is ? classes need scope. In a programming parlance a variables scope is an identifier which declares what portion of a program to which the variable?s identifier can be referenced or accessed. In many programming languages the scope can be local to the procedure, local to a group of procedures or globally accessible i.e. accessed at any point within the program. My suggestion therefore is to adopt a similar scheme for classes. Within the class definition, which includes such options as setting colour, line-weight, dash style and the like, have a scope identifier option, i.e. let the user decide if the scope of a class. What I understand to be a classes? scope is its visibility in respect to layers with which it is active. A local class's scope setting would mean that the class is only visible within or on a particular layer, or if global preference setting is used, the class would be visible to all layers. The group class scope is where things get tricky - How does one reference layers which may not yet exist? I didn?t say I had the total solution just an idea. What do others think? Maybe this concept needs more fleshing out, or maybe I am the only VW user who has had problems with using classes?

[Petri]

I realise that this topic is old and long already.

No offence to anyone, but trying to reduce complexity by adding more complexity does not sound good. As has been noted, the Saved Sheets almost provice a third dimension to the layer/class matrix. Pity that editing this dimension is so awkward to use in unpredictable projects where you create new layers and classes.

For some expressed and implied 'needs' for added functionality, there is another solution that I have advocated for years: each creation tool should have its own default (user-defined) class - perhaps also other preferences. The former already exists for PIOs, well, after a fashion, as it is in the Create Plug-in, not in Preferences of the object tool.

So, text would automatically go to the designated class, lines to another, polygons perhaps to a third.

[Alexandre Villares]

(1) ------------------ wish ------------------

I have a simple idea/wish concerning the effect of new classes/layers on saved sheets:

When you create a new class/layer there could be a checkbox '[X] invisible on existing sheets' (the default being the current behaviour)

(2) ------------------ digression ------------------

I don't like PIOs to have internal parts set to the 'none' class. I can't control their attributes!

The PIOs I write usually have their parts set to the container class. Those internal parts may have three (coded) attribute behaviors:

Class attributes;

User set attributes (at the Attr. Palette);

PIO Coded Attr (i.e. None Fill, dashed line);

If the 'Use at creation' is on at the container class, it overrules my internal attribute settings in a non reversible way.

(3) ------------------ complaint ------------------

Due to a VectorScript limitation I can't make an auto-classing text tool: the CallTool/SetTool doesn't work correctly with the Text Tool

(as you can see if you try to use the Custom Tool/Attributes command with the Text Tool).

[ 03-15-2003, 10:43 AM: Message edited by: Alexandre B A Villares ]