Found Floodeditor, an online MIT licensed tool

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Found Floodeditor, an online MIT licensed tool

William Adams-2
Has anyone come across this before?

https://www.floodeditor.com

I'm flabbergasted that it doesn't seem to have made more of a splash.

William


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

RevarBat
Hadn't seen this one before.  Looks nice, but it has the standard critical flaw of a visual programming system.  Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity.  The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.

There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting!  I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!"  So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous.  But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.

To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.

The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc.  You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen.  Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`.  In a visual paradigm, I have to select and place three nodes.  Something like 4 clicks, scrolling, and a drag per node.  Then two more clicks and drags to connect the nodes. 

Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.

- Revar



On Apr 16, 2019, at 8:44 AM, William Adams <[hidden email]> wrote:

Has anyone come across this before?

https://www.floodeditor.com

I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

doug.moen
In reply to this post by William Adams-2
It looks very slick. I like that you can tweak any numeric literal using a slider and get dynamic feedback. Or click on the node for a solid and it is highlit.

The node based visual programming UI seems clumsy, and the set of shape types and shape operations is pretty limited. I don't think I could be productive using it, in its current state. I get that it isn't designed for me, but even for beginners, I think the UI could be better designed. It is marked "beta" of course.

I was thinking about providing the author with more detailed feedback, but the last code change was June 2015, and there's only one contributor, so it looks moribund.

I will still be pointing novices at TinkerCAD first, and OpenSCAD if they want to write programs.

On Tue, Apr 16, 2019, at 11:45 AM, William Adams wrote:
Has anyone come across this before?


I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

kdtop
In reply to this post by RevarBat
I agree with what you have said.  But it would also be cool if it had the ability to use either the graphical mode OR a text mode.  Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.

Kevin

On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <[hidden email]> wrote:
Hadn't seen this one before.  Looks nice, but it has the standard critical flaw of a visual programming system.  Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity.  The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.

There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting!  I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!"  So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous.  But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.

To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.

The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc.  You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen.  Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`.  In a visual paradigm, I have to select and place three nodes.  Something like 4 clicks, scrolling, and a drag per node.  Then two more clicks and drags to connect the nodes. 

Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.

- Revar



On Apr 16, 2019, at 8:44 AM, William Adams <[hidden email]> wrote:

Has anyone come across this before?

https://www.floodeditor.com

I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

doug.moen
Flood has a "script" object where you can type in an expression.

It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?

On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said.  But it would also be cool if it had the ability to use either the graphical mode OR a text mode.  Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.

Kevin

On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <[hidden email]> wrote:
Hadn't seen this one before.  Looks nice, but it has the standard critical flaw of a visual programming system.  Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity.  The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.

There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting!  I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!"  So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous.  But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.

To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.

The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc.  You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen.  Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`.  In a visual paradigm, I have to select and place three nodes.  Something like 4 clicks, scrolling, and a drag per node.  Then two more clicks and drags to connect the nodes. 

Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.

- Revar



On Apr 16, 2019, at 8:44 AM, William Adams <[hidden email]> wrote:

Has anyone come across this before?


I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

William Adams-2
Apparently the developer has been busy with a startup (higharc.com

A 3rd view where you could hide everything except for designated numerical inputs would work for me, and using the "script" objects allows one to hide a lot of the complexity.

If I could just figure out how to do a difference, I'd be ready to start on at least a small project.

William


On Tue, Apr 16, 2019 at 1:16 PM Doug Moen <[hidden email]> wrote:
Flood has a "script" object where you can type in an expression.

It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?

On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said.  But it would also be cool if it had the ability to use either the graphical mode OR a text mode.  Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.

Kevin

On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <[hidden email]> wrote:
Hadn't seen this one before.  Looks nice, but it has the standard critical flaw of a visual programming system.  Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity.  The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.

There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting!  I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!"  So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous.  But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.

To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.

The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc.  You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen.  Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`.  In a visual paradigm, I have to select and place three nodes.  Something like 4 clicks, scrolling, and a drag per node.  Then two more clicks and drags to connect the nodes. 

Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.

- Revar



On Apr 16, 2019, at 8:44 AM, William Adams <[hidden email]> wrote:

Has anyone come across this before?


I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

doug.moen
According to the source code, SolidSubtract should be a difference, but it doesn't work for me.

On Tue, Apr 16, 2019, at 1:34 PM, William Adams wrote:
Apparently the developer has been busy with a startup (higharc.com

A 3rd view where you could hide everything except for designated numerical inputs would work for me, and using the "script" objects allows one to hide a lot of the complexity.

If I could just figure out how to do a difference, I'd be ready to start on at least a small project.

William


On Tue, Apr 16, 2019 at 1:16 PM Doug Moen <[hidden email]> wrote:

Flood has a "script" object where you can type in an expression.

It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?

On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said.  But it would also be cool if it had the ability to use either the graphical mode OR a text mode.  Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.

Kevin

On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <[hidden email]> wrote:
Hadn't seen this one before.  Looks nice, but it has the standard critical flaw of a visual programming system.  Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity.  The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.

There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting!  I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!"  So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous.  But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.

To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.

The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc.  You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen.  Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`.  In a visual paradigm, I have to select and place three nodes.  Something like 4 clicks, scrolling, and a drag per node.  Then two more clicks and drags to connect the nodes. 

Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.

- Revar



On Apr 16, 2019, at 8:44 AM, William Adams <[hidden email]> wrote:

Has anyone come across this before?


I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

tp3
In reply to this post by doug.moen
On 16.04.19 19:16, Doug Moen wrote:
> Has anybody used software that works this way? Links?

I have not actually used it myself, but ICEStudio works
that way (https://github.com/FPGAwars/icestudio) - which
is a visual editor for Verilog.

ciao,
   Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

William Adams-2
In reply to this post by doug.moen
Thanks! That was my interpretation as well, but I was stymied by it not working either --- guess I'll have to raise an issue on github.

William


On Tue, Apr 16, 2019 at 1:55 PM Doug Moen <[hidden email]> wrote:
According to the source code, SolidSubtract should be a difference, but it doesn't work for me.

On Tue, Apr 16, 2019, at 1:34 PM, William Adams wrote:
Apparently the developer has been busy with a startup (higharc.com

A 3rd view where you could hide everything except for designated numerical inputs would work for me, and using the "script" objects allows one to hide a lot of the complexity.

If I could just figure out how to do a difference, I'd be ready to start on at least a small project.

William


On Tue, Apr 16, 2019 at 1:16 PM Doug Moen <[hidden email]> wrote:

Flood has a "script" object where you can type in an expression.

It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?

On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said.  But it would also be cool if it had the ability to use either the graphical mode OR a text mode.  Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.

Kevin

On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <[hidden email]> wrote:
Hadn't seen this one before.  Looks nice, but it has the standard critical flaw of a visual programming system.  Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity.  The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.

There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting!  I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!"  So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous.  But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.

To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.

The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc.  You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen.  Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`.  In a visual paradigm, I have to select and place three nodes.  Something like 4 clicks, scrolling, and a drag per node.  Then two more clicks and drags to connect the nodes. 

Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.

- Revar



On Apr 16, 2019, at 8:44 AM, William Adams <[hidden email]> wrote:

Has anyone come across this before?


I'm flabbergasted that it doesn't seem to have made more of a splash.

William

_______________________________________________
OpenSCAD mailing list

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

William Adams-2
In reply to this post by tp3
Arguably Illustrator is a visual tool for PostScript --- or Inkscape for SVG.

There are some graphical tools for the various TeX related drawing tools such as xasy for Asymptote and metagraf for METAPOST.

It's discussions like this which make me miss Display PostScript and Altsys Virtuoso's custom PS fills and strokes.

I wish that Solvespace could be a visual editor for OpenSCAD files though.

William


On Tue, Apr 16, 2019 at 2:12 PM Torsten Paul <[hidden email]> wrote:
On 16.04.19 19:16, Doug Moen wrote:
> Has anybody used software that works this way? Links?

I have not actually used it myself, but ICEStudio works
that way (https://github.com/FPGAwars/icestudio) - which
is a visual editor for Verilog.

ciao,
   Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Found Floodeditor, an online MIT licensed tool

William Adams-2
Turns out you have to hide the input geometry as noted at:


and SolidSubtract works as expected.

William


On Tue, Apr 16, 2019 at 2:27 PM William Adams <[hidden email]> wrote:
Arguably Illustrator is a visual tool for PostScript --- or Inkscape for SVG.

There are some graphical tools for the various TeX related drawing tools such as xasy for Asymptote and metagraf for METAPOST.

It's discussions like this which make me miss Display PostScript and Altsys Virtuoso's custom PS fills and strokes.

I wish that Solvespace could be a visual editor for OpenSCAD files though.

William


On Tue, Apr 16, 2019 at 2:12 PM Torsten Paul <[hidden email]> wrote:
On 16.04.19 19:16, Doug Moen wrote:
> Has anybody used software that works this way? Links?

I have not actually used it myself, but ICEStudio works
that way (https://github.com/FPGAwars/icestudio) - which
is a visual editor for Verilog.

ciao,
   Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org