Thomas Wagensommerer

This is a very old wish list item. The problems with objects spanning several stories are still not solved.

Wish granted - Thank you!

If you stretch a palette until it is much wider than tall, it should have its title bar on the left side. ClarisCAD had this feature in the eighties.

Just the lines, please. I am not asking for a replacement for OmniGraffle.

I expected more users would be interested in improving the user interface for levels. In order to communicate the idea better I made a better mockup picture.

Yes connector lines. Marionette already has them, so I think it should be doable. Although for Circuit Diagrams we would need them to be orthogonal, and not necessarily connected to a node.

I hope this made sense. If not, I humbly apologize. I have no experience whatsoever with Lighting Objects.

If I were the developer for your new Lighting Fixture tool I would want a spot to be like a regular symbol, a led stripe behave like a line or polygon and a lighting screen behave like a rectangle. Currently this is not possible within a single tool. So I suggested a new type of object for plugin development.

Those objects are meant to be new types for plugin development.

This tool would need my proposed "Flexible Plugin Object". Depending on menu choice you would want a point object, linear object or rectangle object.

I think a new polygon or object type would be the right choice. A constraint suitable for multiple objects sounds difficult to achieve and for the moment I can't think of any object that would actually need that. This is what I meant: If you use a charting program, and you draw a diagonal line, it will actually result in a L or Z shape connecting the two points. If you modify this shape, handles are at the end points and in the middle of the sides.

I wish there were a polygon, where all sides are restrained to be strictly vertical or horizontal. This would be useful for Flow Charts, Circuit Diagrams, Organizational Diagrams and more.

1.) New Rectangle Object The rectangle object should behave more like a standard rectangle. 2.) Auto Bound Object The AutoBound Object should behave like a Space or a Slab. 3.) Flexible Object The flexible object can change ist behavior from inside by code. It can behave like a Point, Linear, Rectangle or 2D Path Object.

"Overrides" are always a less-than-ideal solution. The design goal for building materials should be that we don´t need overrides in 99,5% of the cases. A bad example would be wall styles, where we need "overrides" in the form of duplicate styles, unstyled walls etc. all the time.

If materials are imported from the resource manager, import of classes from standard files should also be possible in the resource manager.

Building materials need seamless integration into the system of classes. Under no circumstances should the user be forced to duplicate a building material using classes.

I agree. Do we all have to talk to sales individually or is there any official information?

I gave this Feature request a lot of thought. I think the solution could be as follows: At creation any open polygon should be without fill. This would be the desired result in 99% of cases. After that everything should be as it is today. If you need it filled, based on my unscientific guess in 1% of cases, there would be one additional work step. So in 99% of cases you would save one work step.

Materials must be assignable to any object, including 2D objects.

Yes.

Touching the mouse with two fingers should be the equivalent to holding down the option key. So if you have "Mouse wheel zooms" activated you would scroll with two fingers and zoom with one finger. Otherwise you would scroll with one finger and zoom with two fingers. A third gesture, maybe three fingers on the mouse, would activate the flyover tool.

Now let me explain why I suggested, that objects should carry their levels along, when pasted into a different drawing. This is based on an educated guess how the level system is coded inside a wall or a plugin object: If numerical data is entered, it is stored inside the wall or the plugin. If you enter a level instead, neither numerical data nor the name of the level is stored, only an internal reference to the level. Thus, if you copy the wall or the object to a different file, the reference will loose its source and the object creation will fail. For this reason I suggested, that the object should carry its levels along. Which would mean, that the name and the numerical data should also be stored inside the object. If you copy the object to new drawing, the code would first look for the internal reference. If it is there, everything is good. If not, it would look for a level with the same name. If a matching named level is there, it will link to that levels height. Lastly, if there is no matching level, it will create a new one with the internal saved name and numerical height. So copying over an object would never fail.

I remember that time. It was a big improvement after using ClarisCAD on 512 x 384. ;-)

Binding levels to stoies suggest it would not be appropriate to use them in landscape design, carpentry or any other industry that does not use stories. Why not use a level like "Terrace 3" or "Shelf 4". Why call something a story if it isnt. I am not questioning the use of levels at all. I think they are an universal concept and could be much more useful. I am questioning the current implementation which in my opinion does not work well in 95% of the cases. Levels would be extremely useul even in 2D. You could link levels to any kind of object, plugin or symbol like title blocks, annotations, markers, worksheets even when working strictly in 2D. In my opinion the Story + Level System in its current implementation is highly questionable. I agree again. Sorry for capturing your post. I already started a new thread. Your original question of level exchange would be solved by modifing the level system a little bit. I am convinced that we would not loose anything by broadening the concept of levels. Quite on the contrary, everybody would win. I am not against linking levels to stories, only this should be optional and not mandatory.

I would like to suggest some improvements to levels. The first and most important thing would be a simple list of levels, displayed in the navigation palette. This list should contain all the information belonging to levels. In this list you should be able to create, edit, copy, paste, duplicate, delete and replace all levels. All operations regarding levels should be possible from this list view. Especially copy and paste from one story to another. There should also be a mechanism to export levels to another file. In this case you would simply go to the level list, copy any desired levels and paste them into the other files level list. In order to move a level from one story to another you would simply drag it in the list, if desired also duplicating it by option-drag. If you want to get rid of a level you should be able to delete it from the list. In that case, there would be a dialog similar to the one, when deleting classes. This dialog should allow you to define a replacement level for the one you are about to delete. Default Levels are nice to have, but not mandatory, because it would be really easy to create a new level. Step 1: From the popup menu select "Create New Level" Step 2: Enter Name and Height (relative to story, layer or absolute height) Step 3: Drag it to the desired layer or story in the list. Finished. There is no step 4. There is a mock-up of the level list to illustrate the concept. (Bear with me there are some typing errors.) When connecting objects to levels pretty much the same list would be displayed in the form of an pop-up menu.