J
jon
Fri, Dec 1, 2017 1:01 PM
I agree about the two files getting separated, and like the concept of
using the comments (even if that is somewhat ugly). Could the comments
be at the very end?
On 12/1/2017 5:13 AM, Chris Camacho wrote:
I've been thinking about this since the thread started and while I'm
no over bothered myself about an extra file being "untidy" I can see
them getting separated - especially by a less technical user (isn't
this for the customiser for the less technical)
Someone mentioned about putting the info in comments, I can see some
people baulking at this but its not as bad as it sounds, and you could
go further and directly embed it into the command set
either way, splitting one thing (and it is really) into two files,
really isn't going to benefit the code blind, and is going to irritate
the OCD, have you seen the crap that some games do to MY home directory!
I agree about the two files getting separated, and like the concept of
using the comments (even if that is somewhat ugly). Could the comments
be at the very end?
On 12/1/2017 5:13 AM, Chris Camacho wrote:
> I've been thinking about this since the thread started and while I'm
> no over bothered myself about an extra file being "untidy" I can see
> them getting separated - especially by a less technical user (isn't
> this for the customiser for the less technical)
>
> Someone mentioned about putting the info in comments, I can see some
> people baulking at this but its not as bad as it sounds, and you could
> go further and directly embed it into the command set
>
> either way, splitting one thing (and it is really) into two files,
> really isn't going to benefit the code blind, and is going to irritate
> the OCD, have you seen the crap that some games do to MY home directory!
JD
Jerry Davis
Fri, Dec 1, 2017 1:47 PM
Now that's a pretty good idea to have the json file appended to the end of
the .scad file.
Something like this maybe?
at end of .scad file:
//Customizer:
//{
// "fileFormatVersion": "1"
//}
it needs to be created/overwritten or "recreated" every time there is a
save of the source file.
This or some other mechanism, that is deemed better.
But I do like this concept. This is truly a win-win scenario.
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer
The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov
On Fri, Dec 1, 2017 at 6:01 AM, jon jon@jonbondy.com wrote:
I agree about the two files getting separated, and like the concept of
using the comments (even if that is somewhat ugly). Could the comments be
at the very end?
On 12/1/2017 5:13 AM, Chris Camacho wrote:
I've been thinking about this since the thread started and while I'm no
over bothered myself about an extra file being "untidy" I can see them
getting separated - especially by a less technical user (isn't this for the
customiser for the less technical)
Someone mentioned about putting the info in comments, I can see some
people baulking at this but its not as bad as it sounds, and you could go
further and directly embed it into the command set
either way, splitting one thing (and it is really) into two files, really
isn't going to benefit the code blind, and is going to irritate the OCD,
have you seen the crap that some games do to MY home directory!
Now that's a pretty good idea to have the json file appended to the end of
the .scad file.
Something like this maybe?
at end of .scad file:
//Customizer:
//{
// "fileFormatVersion": "1"
//}
it needs to be created/overwritten or "recreated" every time there is a
save of the source file.
This or some other mechanism, that is deemed better.
But I do like this concept. This is truly a win-win scenario.
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer
*The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".*- Isaac. Asimov
On Fri, Dec 1, 2017 at 6:01 AM, jon <jon@jonbondy.com> wrote:
> I agree about the two files getting separated, and like the concept of
> using the comments (even if that is somewhat ugly). Could the comments be
> at the very end?
>
>
>
> On 12/1/2017 5:13 AM, Chris Camacho wrote:
>
>> I've been thinking about this since the thread started and while I'm no
>> over bothered myself about an extra file being "untidy" I can see them
>> getting separated - especially by a less technical user (isn't this for the
>> customiser for the less technical)
>>
>> Someone mentioned about putting the info in comments, I can see some
>> people baulking at this but its not as bad as it sounds, and you could go
>> further and directly embed it into the command set
>>
>> either way, splitting one thing (and it is really) into two files, really
>> isn't going to benefit the code blind, and is going to irritate the OCD,
>> have you seen the crap that some games do to MY home directory!
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
NH
nop head
Fri, Dec 1, 2017 2:16 PM
Why not:
/* Customizer:
{
"fileFormatVersion": "1"
}
*/
That doesn't require any changes to the JSON parser, or the OpenSCAD
parser. But it would get interesting if you use an external editor.
On 1 December 2017 at 13:47, Jerry Davis jdawgaz@gmail.com wrote:
Now that's a pretty good idea to have the json file appended to the end of
the .scad file.
Something like this maybe?
at end of .scad file:
//Customizer:
//{
// "fileFormatVersion": "1"
//}
it needs to be created/overwritten or "recreated" every time there is a
save of the source file.
This or some other mechanism, that is deemed better.
But I do like this concept. This is truly a win-win scenario.
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer
The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov
On Fri, Dec 1, 2017 at 6:01 AM, jon jon@jonbondy.com wrote:
I agree about the two files getting separated, and like the concept of
using the comments (even if that is somewhat ugly). Could the comments be
at the very end?
On 12/1/2017 5:13 AM, Chris Camacho wrote:
I've been thinking about this since the thread started and while I'm no
over bothered myself about an extra file being "untidy" I can see them
getting separated - especially by a less technical user (isn't this for the
customiser for the less technical)
Someone mentioned about putting the info in comments, I can see some
people baulking at this but its not as bad as it sounds, and you could go
further and directly embed it into the command set
either way, splitting one thing (and it is really) into two files,
really isn't going to benefit the code blind, and is going to irritate the
OCD, have you seen the crap that some games do to MY home directory!
Why not:
/* Customizer:
{
"fileFormatVersion": "1"
}
*/
That doesn't require any changes to the JSON parser, or the OpenSCAD
parser. But it would get interesting if you use an external editor.
On 1 December 2017 at 13:47, Jerry Davis <jdawgaz@gmail.com> wrote:
> Now that's a pretty good idea to have the json file appended to the end of
> the .scad file.
>
> Something like this maybe?
>
> at end of .scad file:
>
> //Customizer:
> //{
>
> // "fileFormatVersion": "1"
> //}
>
> it needs to be created/overwritten or "recreated" every time there is a
> save of the source file.
>
> This or some other mechanism, that is deemed better.
>
> But I do like this concept. This is truly a win-win scenario.
>
>
> --
> Extra Ham Operator: K7AZJ
> Registered Linux User: 275424
> Raspberry Pi and Openscad developer
>
>
> *The most exciting phrase to hear in science - the one that heralds new
> discoveries - is not "Eureka!" but "That's funny...".*- Isaac. Asimov
>
> On Fri, Dec 1, 2017 at 6:01 AM, jon <jon@jonbondy.com> wrote:
>
>> I agree about the two files getting separated, and like the concept of
>> using the comments (even if that is somewhat ugly). Could the comments be
>> at the very end?
>>
>>
>>
>> On 12/1/2017 5:13 AM, Chris Camacho wrote:
>>
>>> I've been thinking about this since the thread started and while I'm no
>>> over bothered myself about an extra file being "untidy" I can see them
>>> getting separated - especially by a less technical user (isn't this for the
>>> customiser for the less technical)
>>>
>>> Someone mentioned about putting the info in comments, I can see some
>>> people baulking at this but its not as bad as it sounds, and you could go
>>> further and directly embed it into the command set
>>>
>>> either way, splitting one thing (and it is really) into two files,
>>> really isn't going to benefit the code blind, and is going to irritate the
>>> OCD, have you seen the crap that some games do to MY home directory!
>>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
MK
Marius Kintel
Fri, Dec 1, 2017 3:40 PM
As a quick-fix, there is already a patch in which disables saving this JSON file if it’s not needed.
Also, keep this in mind when considering a redesign of how to manage user-presets for the customizer:
One of the reasons for accepting an extra file as part of this experimental feature was the idea that once we implement package management and dependency tracking of (external) libraries, we may need some sort of project file tracking such dependencies.
-Marius
As a quick-fix, there is already a patch in which disables saving this JSON file if it’s not needed.
Also, keep this in mind when considering a redesign of how to manage user-presets for the customizer:
One of the reasons for accepting an extra file as part of this experimental feature was the idea that once we implement package management and dependency tracking of (external) libraries, we may need some sort of project file tracking such dependencies.
-Marius
JB
Jordan Brown
Fri, Dec 1, 2017 9:47 PM
On 11/30/2017 1:55 AM, Torsten Paul wrote:
It's additional data that belongs to the model file itself.
But is it?
You could have one model and have numerous parameter sets that customize
that model in different ways.
What's more, you might get a new version of the model from its original
source, and want to apply your parameters to that new version.
It sure sounds to me like a parameter set is an object in its own right,
that refers to the model that it's used for. You should be able to load
parameter sets, save them (or not), "save-as" them, et cetera.
(It also seems like that object could be implemented as a structured
.scad file that did an "include" or "use" of the actual model, rather
than being a separate specialty format, but that's an implementation
detail.)
On 11/30/2017 1:55 AM, Torsten Paul wrote:
> It's additional data that belongs to the model file itself.
But is it?
You could have one model and have numerous parameter sets that customize
that model in different ways.
What's more, you might get a new version of the model from its original
source, and want to apply your parameters to that new version.
It sure sounds to me like a parameter set is an object in its own right,
that refers to the model that it's used for. You should be able to load
parameter sets, save them (or not), "save-as" them, et cetera.
(It also seems like that object could be implemented as a structured
.scad file that did an "include" or "use" of the actual model, rather
than being a separate specialty format, but that's an implementation
detail.)
JB
Jordan Brown
Fri, Dec 1, 2017 9:55 PM
On 12/1/2017 1:47 PM, Jordan Brown wrote:
What's more, you might get a new version of the model from its
original source, and want to apply your parameters to that new version.
For extra-extra points - and yes, there are a million difficult details
- don't require the user to download and store the actual module file.
Have the parameter set include a URL reference to the module file (which
might be, for instance, on thingiverse) so that it's automagically
retrieved at need.
Same applies to libraries; let a library reference be a URL so you don't
have to manually retrieve and maintain all of your libraries.
On 12/1/2017 1:47 PM, Jordan Brown wrote:
> What's more, you might get a new version of the model from its
> original source, and want to apply your parameters to that new version.
For extra-extra points - and yes, there are a million difficult details
- don't require the user to download and store the actual module file.
Have the parameter set include a URL reference to the module file (which
might be, for instance, on thingiverse) so that it's automagically
retrieved at need.
Same applies to libraries; let a library reference be a URL so you don't
have to manually retrieve and maintain all of your libraries.
TP
Torsten Paul
Fri, Dec 1, 2017 10:16 PM
On 01.12.2017 22:47, Jordan Brown wrote:
Yes, in the current design, it is. Also, at this point, it's a GUI
only feature, not visible in the language.
There's probably a number of other options that could be explored.
We'll see how it evolves.
ciao,
Torsten.
On 01.12.2017 22:47, Jordan Brown wrote:
> But is it?
>
Yes, in the current design, it is. Also, at this point, it's a GUI
only feature, not visible in the language.
There's probably a number of other options that could be explored.
We'll see how it evolves.
ciao,
Torsten.
