In my experience, graphical languages can be too "wordy". Creating the graph
for a complex expression is either pointlessly verbose or one turns to a
text-based syntax for those bits. Imagine trying to create, or understand,
the graph for (a+b)/sqrt(1-a*b/c^2). Where it succeeds, it does so in fields
that text is wholly unsuited for. Labview nodes are inherently complex in
themselves, giving a small graph large expressive power, and Z100 is
representing an organization that text struggles with (a
finite-state-machine). The only mainstream benefit of a graphical language,
in my opinion, is where it is reducing the knowledge barrier in such cases
as Scratch, where learning the necessary syntax is a significant
disadvantage. And even in those cases effort must be expended in producing a
graphical interface that is inherently obvious -- Scratch fits nodes
together like a jigsaw puzzle. Dumping a library full of seemingly identical
nodes on the user with generic arcs to connect them all would confuse them
more than a textual syntax. Labview carefully arranges its library into
related groups with comprehensive help-text and even then it can be baffling
at times.
Graphical programming has been a concept for many years. I was using it in
the early 1980's. But we are mostly still using generic text editors when we
want to write a serious program. To my mind there is a good reason for that.
--
View this message in context: http://forum.openscad.org/Fusion360-and-OpenSCAD-tp18493p18535.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2016-10-05 01:38, Richard Urwin wrote:
Graphical programming has been a concept for many years. I was using it
in
the early 1980's. But we are mostly still using generic text editors
when we
want to write a serious program. To my mind there is a good reason for
that.
Agreed. This is why the text-based approach in OpenSCAD is a good idea.
Carsten Arnholm
as a "language" graphical languages may have issues but I think the idea
behind the original post was:
it would greatly help usability and productivity in OpenSCAD (for making
arbitrary objects) if there were snap-to capabilities (vertices, centers of
faces, cetroids of solids). I've been musing on this just about every day
I use OpenSCAD.
The math / programming aspects of OpenSCAD are nice for making math based
shapes, visualizing equations, etc.
But if you have an arbitrary idea for an object in your brain snap to
capabilities and the like (such as offsets from snap to in various units)
and a bigger variety of primitives would be a big help. And drawing
capablities would also help.
Another way to approach it is some kind of "marriage of tools" where one
CAD suite provides that and OpenSCAD concentrates on the math side but both
can import / export from each other. If you were importing into OpenSCAD I
would fully expect that the autogenerated code or whatever would look
horrible.
I have fun using OpenSCAD but also find it very frustrating and tedious at
the same time, marrying it with some other Open source CAD tool (which
works more graphically) would greatly increase productivity for the end
users.
On Wed, Oct 5, 2016 at 3:45 AM, arnholm@arnholm.org wrote:
On 2016-10-05 01:38, Richard Urwin wrote:
Graphical programming has been a concept for many years. I was using it in
the early 1980's. But we are mostly still using generic text editors when
we
want to write a serious program. To my mind there is a good reason for
that.
Agreed. This is why the text-based approach in OpenSCAD is a good idea.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 10/06/2016 01:25 AM, Dan Shriver wrote:
But if you have an arbitrary idea for an object in your
brain snap to capabilities and the like (such as offsets
from snap to in various units) and a bigger variety of
primitives would be a big help.
More primitives is basically a matter of a maintained
library providing those. There is no real need for the
core to provide that directly.
Another way to approach it is some kind of "marriage of
tools" where one CAD suite provides that and OpenSCAD
concentrates on the math side but both can import / export
from each other. If you were importing into OpenSCAD I
would fully expect that the autogenerated code or whatever
would look horrible.
In general, that's not going to work easily (well, you can
just import files generated by other tools, but I don't
count that as "easy"). I do have some ideas regarding
LibreCAD and 2D sketching. If that ever is going to happen,
I don't know. With the long list of open topics and the
available amount of time, the reasonable guess is
unfortunately: not anytime soon.
ciao,
Torsten.
tp3 wrote
On 10/06/2016 01:25 AM, Dan Shriver wrote:
Another way to approach it is some kind of "marriage of
tools" where one CAD suite provides that and OpenSCAD
concentrates on the math side but both can import / export
from each other. If you were importing into OpenSCAD I
would fully expect that the autogenerated code or whatever
would look horrible.
In general, that's not going to work easily (well, you can
just import files generated by other tools, but I don't
count that as "easy"). I do have some ideas regarding
LibreCAD and 2D sketching. If that ever is going to happen,
I don't know. With the long list of open topics and the
available amount of time, the reasonable guess is
unfortunately: not anytime soon.
I was musing today on extending the language of OpenSCAD by writing my own
compiler and outputting pure OpenSCAD code, much like early C++ compilers
(properly translators or transpilers) output pure C code. That introduces
another step where you have to write your file, translate it to OpenSCAD and
then load the result into OpenSCAD.
However OpenSCAD already makes some of that transparent. It watches the
source file and when it changes it automatically reloads it. Of course that
makes the extra translation step even more obvious to someone used to just
writing the file out and seeing the result.
So how would it be if OpenSCAD had an ability to watch the source file and
then run a configurable script on it before loading the result of that
script. There's various levels of doing that, from a script that is blindly
run on all files, to something that can treat files differently based on
their extensions with macros for the filenames involved. A modular first
hack should be simple to produce and then others with more interest could
extend it as required and send pull requests.
Then OpenSCAD could continue doing what it does and anyone with other ideas
could implement them as simple text-to-text filters without needing to
implement complex GUIs or rendering pipelines.
Another advantage is that the built-in OpenSCAD editor would transparently
work on the real source-code and the ugly autogenerated OpenSCAD code would
never be seen. Of course any errors in that OpenSCAD code would refer to
lines that the user never saw, but a competent compiler should never produce
erronious code.
--
View this message in context: http://forum.openscad.org/Fusion360-and-OpenSCAD-tp18493p18556.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2016-10-06 01:40, Torsten Paul wrote:
I do have some ideas regarding
LibreCAD and 2D sketching. If that ever is going to happen,
I don't know.
To get profiles freom LibreCAD would be nice.
I have been experimenting with extracting 2d profiles from hand
drawings, so they can be used to obtain 3d-printable models.
See for example
http://www.printrbottalk.com/forum/download/file.php?id=11168
In this case the drawing was scanned to .png using a flatbed-scanner.
The image was slightly manipulated before it was processed in some
experimental code to generate 2d polygons representing outer and inner
contours respectively. That's all you need for generating data to be
extruded into 3d.
Obviously this works also when the image is not a hand drawing.
Carsten Arnholm
Or a tool that allows you to position Bezier handles which are then
converted to smoothed lines and then imported into OpenSCAD
Jon
On 10/6/2016 7:33 AM, arnholm@arnholm.org wrote:
On 2016-10-06 01:40, Torsten Paul wrote:
I do have some ideas regarding
LibreCAD and 2D sketching. If that ever is going to happen,
I don't know.
To get profiles freom LibreCAD would be nice.
I have been experimenting with extracting 2d profiles from hand
drawings, so they can be used to obtain 3d-printable models.
See for example
http://www.printrbottalk.com/forum/download/file.php?id=11168
In this case the drawing was scanned to .png using a flatbed-scanner.
The image was slightly manipulated before it was processed in some
experimental code to generate 2d polygons representing outer and inner
contours respectively. That's all you need for generating data to be
extruded into 3d.
Obviously this works also when the image is not a hand drawing.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13154 - Release Date:
10/05/16
On 10/06/2016 01:12 PM, Richard Urwin wrote:
I was musing today on extending the language of OpenSCAD by
writing my own compiler and outputting pure OpenSCAD code,
much like early C++ compilers (properly translators or
transpilers) output pure C code. That introduces another
step where you have to write your file, translate it to
OpenSCAD and then load the result into OpenSCAD.
Nothing wrong with that, people have done that before and
I guess there always be use cases where that's the best
option.
But as always, I'm curious... Why? Which feature?
The other option is to help making OpenSCAD itself better
which will then can benefit everyone who uses it.
Yes, it's more complicated to work together and find
solutions that don't break existing stuff, and yes that
can be frustrating at times, but there's also lots of
things to gain. There's lots of effort going into making
OpenSCAD usable by providing ready to use packages (not
only those on the homepage, but also for lots of Linux
distributions), responding to issues here and on github,
documenting stuff and so on. So while writing code is
obviously an important part, all those other topics and
all the people helping with that are even more important
for an (open source) application to live on.
So how would it be if OpenSCAD had an ability to watch
the source file and then run a configurable script on
it before loading the result of that script. There's
various levels of doing that, from a script that is
blindly run on all files, to something that can treat
files differently based on their extensions with macros
for the filenames involved. A modular first hack should
be simple to produce and then others with more interest
could extend it as required and send pull requests.
I see how that could be a powerful thing, but also sounds
very much like a support nightmare (even without thinking
about cross-platform issues).
ciao,
Torsten.
On 10/06/2016 01:33 PM, arnholm@arnholm.org wrote:
I have been experimenting with extracting 2d profiles from
hand drawings, so they can be used to obtain 3d-printable
models.
See for example http://www.printrbottalk.com/forum/download/file.php?id=11168
Nice, what was used for the image->vector conversion?
The "some experimental code" sounds like it's not using
any existing tool or library?
We still need to work out some of the details, but
https://github.com/openscad/openscad/pull/1110 should
be able to handle at least the simpler cases using
the potrace library.
ciao,
Torsten.
On 10/06/2016 01:49 PM, jon wrote:
Or a tool that allows you to position Bezier handles
which are then converted to smoothed lines and then
imported into OpenSCAD
Not integrated, but still nice way to just draw polygon:
source: https://github.com/daid/OpenSCAD-polygon-editor
ciao,
Torsten.