QCAD.org Forum

Discussion forum for contributors and developers who are using the QCAD ECMAScript development platform or the C++ plugin interface or who are otherwise looking to contribute to QCAD (translations, documentation, etc).

It started with an order of my old mentor in engraving.
He is retired and lives partially in Uganda these days.
The order was to make 14 badges as relation gift.

The first pic is the design I got from him, the second is what I proposed.

ESCU_Commodore.png (64.89 KiB) Viewed 220 times

ESCU_Commodore_v2.png (32.47 KiB) Viewed 220 times

I followed a tube on how to flex the rope manually.
Drew 1 corner with Qcad and cloned it 3 times.

The badges are allready donated a while ago.
Engraving them was a whole other story.
Sharpest detail radius is 0.08mm in engavers brass.

But something kept me coming back to it.
As it was merely slicing the 'painter' and recasting it orthogonal on the bend.
A script could do that.
And it could do that with any 'painter' or lines, dots, ....
It is that versatility that drived me in coding it.

For now, the zip package is intended to be extracted to QCAD\scripts\Misc\Examples\MathExamples\
In there is a subfolder 'FlexPainterTemplates' with 2 dxf drawings.
A tutorial on how the painter is constructed, and one with a bunch of test cases.
On a win system they might beter be moved out of the protected OS portion.

Its stable and works exactly how it is intended.
I came to a point where I need some input of the community.
There is a lot of info inside the script file. Look also for 'ToDo' and 'Issue'.
A large remark block is at the end of the script.
These are not intended as a thousand questions in one post.
They are my guidlines to start asking questions or simply not to forget anything....

It might that the coding is horrible, not Java minded, nor Qcad minded, nor proper coded.
But you have to look at the potential far beyond casting a rope.
As I hate to be verbose the tool is persistent verbose.

I like to hear the others their opinion, and if any, about unknown issues.
In the long run I see it to be promoted out the experimental level.

The math was simply cast left , cast right.
But then it evolved in several stages.
All curve-based
Nice endings.
Apexes.
Dynamically scaling to a closed form (without apexes)
The idee of insertions eg. a knot in this case.
Global casts along the base curve.
Margin crossing.

The FlexPainter having the flaws in steep curves is error-like but it is super realistic.
Twisting a roller stamp to much will smudge.
What about chain-like behaviour?!
Or common stamp like?

But that is all artistic stuff.
Its also a base for more thecnical stuff with a custom well defined painterset.
Repetitive texts if you like.
Splines through offsets at regular intervals.
......
Endless

To have a idea of the actual width....
I was thinking in the way CXF is standarized.
A non-limiting base height of 9 units.
4.5 up & 4.5 down.

Then we could work with actual dimensions instead of a scaler of something hardcoded.

But how will this work out on system or a document not in mm.
The hardcoded stamp is about 3mm high.
(10x actual size on the badges)
On a system in inches the same painter is 3 inch high.

We could keep units for units and only adapt the default scaling on first load to the system/document settings.
Metric then starts with eg. f2.5 and Inches with f 0.1 (same order as 0.09842519...)

Do you have an addressable parameter in scope that tells us what the document it's units are?
With this, I think I can test this route out and perhaps increase the user friendliness.
But that all depends on the yes & no of a circular value conflict.

The painter width is now base9.
By this the user can choose the actual width.
And it was also possible to let the actual painter length and stepsize to be set individually.
PreserveLook overrides these two and revert back to base9 times a factor dictated by the unchanged width.
On first load reasonable defaults are set.
(Still not sure how to handle doc changes)

On PainterSet change two values are needed: the base9 painter length & the base9 painter stepsize.
These are set by a function FlexPainter.prototype.PainterSetInit(painterSet) part of Flexpainter.js script.

With inserting a multitude of 'debuggers;' and canceling the Dialog every time,
I still could evaluate one widget dialog change functions at a time before the dialog itself terminates.

I'm stuck on the fact that when the on change functions run the data is out off scope.
(This is starting to begin to be the story off my Qcad experience)

I've looked up the use of '.connect' in the master scripts and tried some things out.
I don't get further then declaring copies in the FlexPainter.prototype.initWidgets function.
After declaring they remain static and don't reflect the PainterSet change.

As an on change functions runs the flexpainter functions are also out off scope.
Can't find a way to run the FlexPainter.prototype.PainterSetInit(painterSet) function.

Is there a proper way so:
On PainterSet change my data storage reflect the change?
The on change functions have access to that data?

I don't include the new sources because they are corrupt without a solution.
I can PM them for evaluation as long as the dialog is cancelled.

I tend to use qDebug("..."); rather than debugger statements, especially with dialogs. The debugger can change the order in which events are processed and even lead to crashes. Feel free to PM the sources and I will have a look. That would have to wait till next week though.