Appeal for API/SDK Support in Chief

[gteacher]

Appeal for API/SDK Support in Chief

There have been numerous references here in support of the idea of having an API/SDK in Chief (mostly in the Suggestions and ChatRoom threads). Chief has been mostly silent on this topic with only vague promises of some future consideration. At this point, it doesn’t look like (to me) that Chief intends to do anything significant on this issue in the near future. I don’t expect any significant expansion of RUBY’s capabilities in this year’s release of X6 or any near movement to begin the groundwork for an API.

The reasoning appears to be, understandably, the lack of interest on the part of the average (novice) user. Their logic is simple: This site has approx. 20K users and when this topic is addressed they only receive a few responses in agreement on this theme. These limited responses get “lost” among the several thousand suggestions they now have in their suggestions database.

It is unfortunate that an API/SDK has been tied to the Ruby script language here. It only serves to confuse and give the impression to the casual user that an API/SDK would turn Chief in to a programmer’s tool. NOT TRUE.

An expansion of Ruby to implement such a feature(s), properly implemented, would be no more difficult to use, for the novice, than any other Chief tool and certainly NOT require any significant programming abilities. At present there are some serious limitations in Chief’s implementation of Ruby which prevents its use in this direction. This is not a resource or finance issue but a business decision about the interests of its users.

This is a “chicken or egg” issue. Most people are not aware of the capabilities possible unless they see some significant demonstration of use. Significant use is not possible without enhancement of the present tools now available. Therefore: interest remains in a never land.

I don’t believe that work in this area would take away resources for the other pet projects voiced here. A logical first step may be only for Chief to join one of the independent, non-profit, development support groups sustaining Ruby. A upgraded Ruby engine and interface would only provide a path to more easily clear up some of the limitations in Chief regarding a API/SDK and BIM’s, material lists, schedules, labels, Web exchange, etc. and a myriad of other tools in Chief that are a “great idea” but now too limited for practical usage.

If you agree that Chief should address some of the present limitations with the Ruby script engine, Chief needs to hear from you ELSE nothing more will be done in this area in the immediate future (next several revs.). The present bottlenecks will remain and probably decline into obscurity.

Please send a brief e-mail regarding your support or not to:

support@chiefarchitect.com or suggestions@chiefarchitect.com

(One sentence is best). Otherwise this is pretty much a non-issue for the time being (years).

Note: I am somewhat reluctant to make this post as a lack of response would only reinforce Chief’s present impression that there is no noteworthy user interest in this area. If I have the wrong impression, I invite Chief’s management to comment.

If you are a novice user or expert and would like to see some of the anomalies in Chief cleared up through the expansion of the Ruby script engine and a possible API with true BIM capabilities, now’s your chance to influence the future direction of Chief.

[perryh]

I agree with you Gerry but there might be a dozen users here, that care out of 20,000. Small odds for sure. I guess we just have to keep up the pressure on the chief's hoping they see it also. We are just trying to make this program better for all. Some people may not think they need it , but they do, to make their job easier in the long run.

[dshall]

I think we don't know what we don't know. But based on what I know about Gerry, he knows more than I, so what he is referring to I am sure would be a benefit to all of us.

[lbuttery]

Gerry:

you know that I am one of the few

but you also know that we are "spitting in the wind"

it ain't gonna happen

I have read CA's replies on this subject and they just don't get it
so if they don't understand it and see the benefits they will never go down that road

They are convinced that Chief is "the best it can be" and are clueless as to what power they could unleash

Lew

[gteacher]

Gerry:

I have read CA's replies on this subject and they just don't get it
so if they don't understand it and see the benefits they will never go down that road
Lew

That's pretty much true. The original geniuses that put this program together 20 years ago are now honorably just watching the world go by. But they have a new corp of "geniuses" that understand the issues. They just need to take the "chains' off. That isn't going to happen without user support. Chief still understands business.

[Glenn Woodward]

Gerry,

Would it be possible for you to expand on the beneficial differences between Ruby development as opposed to an API/SDK implementation?
Are they mutually exclusive or can they both be developed and work concurrently?
My basic knowledge would have me believe that an API/SDK would be more flexible and powerful than Ruby.
Is one better than the other?

[David J. Potter]

As a long time user, I would need to have examples of things that are useful that I could do with such a set up, however applied, in other words how would it help me and Joe Blow out here in the sticks?
What could I then do that I cannot now do or do quicker-easier?

Like Scott said, I do not know what I do not know. If it is useful, old dogs certainly can learn new tricks.

DJP

[lbuttery]

David:

it would be the same as symbol making and using molding polylines

some Chiefers would be "creators" and others would be "users"

I have no idea how to make a symbol nor the skill - but I do know how to use those that are created by others

Lew

[lbuttery]

Glenn:

I would like to see both the API/SDK and RUBY


we also need a macro recorder like Excel and Word and many, many other apps have

Lew

[yusuf]

Software developent kit(sdk) that would be very nice to use other apps integrated with chief.
Lew, i am having problems in some stractural analysis in staad, using macros in excell sheet data intery,. And auto creation of the frame geometry is still mystry to me. Does that need high level understanding of programming? i dont know if you just give me the password in short, i like it but couldnt understand.
Regarding chief symbol creation, i can tear the roof and do this for you if you need some.

[gteacher]

Glen: - sorry for the delay – watching game.

A softball if I ever saw one. Since you know the answer, I’ll take the inference and elaborate.

Yes, they are mutually exclusive, but together they form a symbiotic relationship. SDK’s usually fail because they are poorly implemented and require too much programming knowledge and effort to implement to be of any real benefit. Usually, they are just too complicated to get any time benefit from them.

Ruby fills this requirement, it's as simple as writing a script and placing it within a directory. It is unquestioned now as the premier string handling program; as easy or complicated as you need with converts from virtually all languages. Ruby has built in modules and support for most languages, web support, .net support, is platform independent, has module inter- communications, has thread and network support, well documented, several levels of security, updated regularly with a good, knowledgeable support base. AND its free. Using SDK functions or scripts within ruby would be as easy a writing any job sequence. No need to worry about declaring variables, compiling or observing some obscure protocols. Feedback is immediate. Files and scripts are “human” readable and easily disseminatible as just copying a text file. No need to worry about what platform it runs on or what the installation limitations are. Ruby runs better on Unix then windows as Unix was its primary development platform. No need to worry about the operating system.

Ruby is NOT a SDK, but a means to utilize a SDK for both the novice and expert user. It takes the need for programming skill out of the question and provides a multitude of methods to search, organize, and manipulate the data in a logical, efficient manner. It also provides a path to utilize third party plug ins which can be easily replaced when they become obsolete. It provides a path for the SDK to communicate and interface with any of the user's plugins. A SDK needs to be no harder to use than any of the other tools in chief. Chief is NOT directed to programmers, but designers. Ruby fills that need.

[lbuttery]

A SDK needs to be no harder to use than any of the other tools in chief.

Gerry:

I agree with your synposis except for this statement

there are many chiefers that will never create or understand Ruby scripts
some may have trouble even understanding how to use them

remember - there are chiefers who don't even understand simple file management

but - there are other chiefers who will be able to make chief sing ....

Lew

[lbuttery]

i am having problems in some stractural analysis in staad, using macros in excell sheet data intery,. And auto creation of the frame geometry is still mystry to me. Does that need high level understanding of programming?

Yusuf:

maybe ???

with a macro recorder in Excel it is possible to turn on the recorder
do the various clicks etc for a task then save the recorded macro

then each time the recorded macro is run those clicks will be repeated

however, most of the time it will be desirable (maybe necessary) to edit the recorded macro
and enhance it

those edits will require "programming"
ranging from simple to complex depending on many factors

Lew

[gteacher]

David :

Your question is better framed in view of what features you don’t utilize now in Chief because they are too cumbersome to bother with.

I’m referring to material lists, schedules, component lists, cost estimates, material and job schedules, rescheck, HVAC load cals,BIM, inter-client communication, web site updates, mass item updates and modifications, area cals, excavation\ fill cals, structural checks, code checks, vendor material listings, vendor cost estimates and updates. Real time Vendor interface for material estimates and availability. In short, there is a whole range of services that you could provide and charge for with little effort on your part.

Also processes to automate repetitive details such as: Libraries of editable construction specs and instructions with one key insertion. Macros for repeated sequences. Icons to initiate third party software and for command sequences in Chief. Automatic compilation of fixture and material lists for bid. Sorting by any basis you choose. Formats and listings based on your need not Chiefs. In short, a more efficient method of working.

Of course, none of the above is believable until something is demo’ed. The more resources that are opened up to us, the more applications we can imagine.

[Glenn Woodward]

Gerry,

Thanks for the info.
I started cad with Generic CAD and then Visual CAD.
Generic CAD had a powerful scripting language that I made full use of. I remember doing a very large module that parametrically drew AC ducting.
Visual CAD has both a comprehensive API/SDK and a scripting language.
I didn't do much with the API, but all sorts of add-ons were available.
The scripting language was pretty straight forward and useable by a lot of the users. It could run a dll file which sounds like that interface between the API and the scripting language you mentioned.

Thanks for the insight and taking the time to explain.


PS,
This is a simple script example. It is easily acomplished and fulfills the need for when you say "I wish I had a tool that ........".
Easy, just create the tool - this one would take about 10 minutes to create by a fairly competent user..

The following script is intended to be launched while you are dragging a symbol, prior to placement. The script causes Visual CADD to prompt you to click on a line in the drawing, then matches both the symbol rotation and Ortho angle to the angle of the line. The script then initiates the Track command, allowing you to place the symbol at a desired location on or in relation to the line:
SymRot;=;OrAngVar;$SymRot;TK;
SymRot is the native command that sets symbol rotation. = causes Visual CADD to wait for you to click on a line (or other object) that has the desired angle. OrAngVar is the native command that sets the ortho angle. The ortho angle value is set by $SymRot, which is the system variable that holds the newly set value for the symbol rotation. Finally, the Track command, TK, is initiated, and the tracking direction will match the angle of the target line.