Console App versus GUI? RESOLVED a GUI

[Joseph1916]

Could a Console Application window be a more suitable solution for COGO?
As with QCAD, an API, tend to be Graphically oriented.
COGO not as much so.

Engineers and Surveyors are more exacting with their results than Drafting is within their results.
If so, is it a waste of time to develop a Console (text) Application??
Or perhaps not even possible??

If not possible, then a GUI is the answer. COGO will have found a new home. :-) Just curious. My partner says GUI, I lean towards Console !!

Joseph1916

[CVH]

Joseph1916,

Difficult to answer because we don't know what the goal is.
And then I mean not in details.
We've seen you struggle with simple sample QCAD scripts, but nothing like "I have this data and I want that result."

Nowadays most things are more graphically simply because computer graphics evolved very hard and are still evolving fast.
Raw textual data is usually hard to visualise for humans, binary data is even harder to interpret but dedicated code can visualise both with ease.
In reverse, data from a draft can easily be exported in whatever textual or binary style required.

Reading this: https://help.autodesk.com/view/MAP/2022 ... 4BB22762F1
Then a so-called 'COGO Input dialog box' would be easy to implement in QCAD.
Not knowing for sure if that is the goal.

Regards,
CVH

[Joseph1916]

CVH

Finally, getting back with you..... I'm going with the GUI... the more modern approach, as your Auto-CAD examples demonstrate.

Beyond that, I am going to Post code for a 5 Column by 1000 row array in JavaScript to store Survey field Points.

The 5 Columns Are:
Point Number
Eastern
Northern
Elevation
Description

We plan to migrate to the C Programming Language, eventually, so I reference cJSON. I suspect you are familiar with the cJSON library. Could come in handy as a STANDARD to read/write/modify the use of JSON in C. cJSON come along with an API.

I will post the Array Code shortly.

Joseph1916

[CVH]

Joseph1916,

A list of 1000 points with (Point number, Y, X, Z, Description) can already be imported if presented as CSV:
https://qcad.org/en/tutorial-importing- ... s-from-csv

You can extend QCAD functionality with C++ libraries but natively you work in ECMAScript:
https://www.ribbonsoft.com/en/qcad-scripting

JSON is supported out of the box in ECMAScript ... 'JavaScript Object Notation'
Built in function for converting JSON strings into JavaScript objects: var object = JSON.parse(jsonTextString);
In reverse: var jsonTextString = JSON.stringify(object);
And very similar for arrays or a mix of things, all within JSON limitations/restrictions.

Regards,
CVH

[Joseph1916]

CVH

Thank you for your reply....... Very helpful....

I stumbled across something that at first was confusing me, now I can see why....

The "prompt method" was not working as I thought it would with Node.js ....
Now I am understanding the issue.... how to handle user input synchronously in Node.js.
I am seeing synchronous and asynchronous communications as the issue ..

Now I can rest......

Joseph1916

[CVH]

The "prompt method" was not working as I thought it would with Node.js ....

Not knowing what Node.js has to do with QCAD.
https://www.qcad.org/rsforum/viewtopic.php?f=32&t=9662

Regards,
CVH

[Joseph1916]

CVH

OK, thank you for pointing out the Technology differences between node.js a QCAD. And it is different, very different.

My work around will be to have Utility Functions outside of QCAD, using Node.js, and simple sharing the output data, until a better solution become available. I do this in the interest of filling the gaps in my approach. Perhaps others can find better solutions. We will have results to look at.

I could see Python processing output files that could be useful. I will use any Utility at my disposal.

My first out put file will be a table of a two-dimensional array of point values, that can be manipulated.

Joseph1916

[Joseph1916]

Sorry for re Posting.... Minor update, the file format I will USE is JSON. I have been reading on it, and it is a common interchange format, oriented towards JavaScript (JavaScript Object Notation).

[CVH]

it is a common interchange format, oriented towards JavaScript (JavaScript Object Notation).

Yep, already mentioned 4 & 5 posts up:

JSON is supported out of the box in ECMAScript ... 'JavaScript Object Notation'

Array based or object based ( [...] or {...})?
Or mixed?

An array of points is easy to iterate.
Creating an RVector for each, at that location an RPoint and adding additional data as custom properties.
You will need to implement a specific QCAD import tool .... A script.

The required functionality exceeds the Simple API.

Regards,
CVH

[Joseph1916]

CVH

Support for JSON will be very helpful going forward. The original TOPIC is resolved. COGO will use a GUI ..... TOPIC RESOLVED

Thank you for your support......

Joseph1916

[siyagomes]

Could a Console Application window be a more suitable solution for COGO?
As with QCAD, an API, tend to be Graphically oriented.
COGO not as much so.

Engineers and Surveyors are more exacting with their results than Drafting is within their results.
If so, is it a waste of time to develop a Console (text) Application??
Or perhaps not even possible??

If not possible, then a GUI is the answer. COGO will have found a new home. Just curious. My partner says GUI, I lean towards Console !!

Joseph1916

Developing a Console Application for COGO can be practical, offering precision and ease of use. It's not a waste of time; it caters to a specific audience seeking efficiency. GUI remains an option, but the Console serves a purpose.

[Joseph1916]

Interesting. Your points were what I saw.

But that would leave me building a Console Application in Qt5. That would require some guidance from others to keep me on track. I could still have questions.

And a major issue is my Development Environment.

I am 100 percent Linux, because of cost issues. I am very restricted because of that.

Relocation out of the U.S. is always on the table.

This is moving towards a Console Application in Qt.

Joseph1916