Spreadsheet module

Info about new community or project announcements, implemented features, classes, modules or APIs. Might get technical!
PLEASE DO NOT POST HELP REQUESTS OR OTHER DISCUSSIONS HERE!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Spreadsheet module

Post by ickby »

I agree with juergen, a spreadsheet which sets properties on it's own will mess things up tremendesly, especially as many users already don't get the object dependencies even without this extra layer. I think we should keep the document solving as it is now, but I had a little idea how both can work nicly together, here how it could work:

1. Introduce a new object type into the core system called data object. This object only holds one of the new property maps which can be used to store all kinds of name - data pairs. This object can be used to allow other objects to get data from. Therefore the data object gets added as dependency to the document object using it to query data from. The inlist and outlist of all document objects would resemble the relationships as needed by the document solver.

2. But that would mean to change all numerical properties to somehow allow the user to put in the name of the referenced data object and the name of the data inside it's property map. This would be a tremendous effort, HOWEVER: currnently most numeric properties get exchanged anyway, so it would only mean to allow the new property quantity to accept the dataobject name and value key. Once the user adds e.g. "mydataobject.value1" into the new input field the document objects inlist and the data objects outlist get updated to reflect this dependencie. If the property quantity gets queryed for the numerical value it gives back the value stored in the data object.

3. A spreadsheet onject would be derived from the data object type and fill the property map with all data it may want to expose. It could be possible to create named fields in the spreadsheet which are exposed, or expose by row-coloum id, there are many possibilities. No matter how complicated the internal calculations are, it exposes only simple values and therefore it dos not break the linear document solving. This can be easily done in a module as the needed itneraction functionality is available in core components (data object and input field)

4. create the Spreadsheet in such a way that if it querys data from any object it sets the object as dependencie accordingly by keeping the inlists and outlists up to data.

This would give the document solver a full understanding of the data dependencies and if the user creates some nonsense (e.g. cylic dependencys) it would be recocnized. Another advantage is that I can think of quite a few more kinds of data objects which would be handy, so with this generic type many cool things can be added.

Annother advantage: when the user looks at his property he sees instantly that it references a value from somewhere alse. This is less confusing than a always changing value updated by the spreadsheet itself with no reference why it changes.
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Spreadsheet module

Post by yorik »

Okay, I agree with you guys, but this is a huge undertaking, way bigger than what I had in mind, and frankly I'm not so interested in that behaviour to spend so much time coding it. That thing I added to the spreadsheet is only because some people asked for it and it was quick to code... But yes, of course it is mostly a hack, and far from proper freecad behaviour.

So what would you suggest for now? Do I remove the cell controller stuff? Do we leave it?
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Spreadsheet module

Post by jriegel »

Ickby is on the right track, with one exception.
e.g. on your 3. Normally we take care (e.g. in PartDesign) that the dependency is a directed acyclic graph. In case of an in-out-list we have to assume the user build a non cyclic dependency (out list points before and after in the history tree). Since the user can set in's and out's to what ever he want, we can not easily handle this. At least the document can check on cyclic dpendencies...

@Yorik.
Let in be, I see it as kind of real live experiment ;) But we have to be aware it can cause trouble...

Another option is to use the spreadsheet like a dialog. Only solve it if its "open" and save to the document if the user click Ok or Cancle. Then the two solver are seperated....
Stop whining - start coding!
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: Spreadsheet module

Post by tanderson69 »

jriegel wrote:Another option is to use the spreadsheet like a dialog. Only solve it if its "open" and save to the document if the user click Ok or Cancle. Then the two solver are seperated....
I am working on something similar and I came up with the same conclusion. Calculate the purely numerical graph first and log changed expressions to touch dependent features. Do document recompute and let features containing expression observers pull down the changed values. Not to highjack the thread, but here are a couple of pictures.

ExpressionGraph.png
ExpressionGraph.png (294.1 KiB) Viewed 4495 times
ExpressionsDialog.png
ExpressionsDialog.png (65.33 KiB) Viewed 4495 times
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Spreadsheet module

Post by triplus »

I do not know about the technical part but from user/engineering point of view capability like this is invaluable. This is the stuff that will take new Assembly Workbench to the next level when both modules combined.

I still did not find a way how to control sketcher dimension and i guess this is not available yet but for controlling Feature Property i did manage to achieve that.

About technical part couldn’t current document solver be used and Spreadsheet Module just to be one more "client" just like "end user" is ATM? Data is fetched and displayed on the screen or in the Cell and when it is changed current document solver does it's job?

Or is this part of exchanging the information that hard part you are talking about in the first place?
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Spreadsheet module

Post by triplus »

tanderson69 wrote:
jriegel wrote:Another option is to use the spreadsheet like a dialog. Only solve it if its "open" and save to the document if the user click Ok or Cancle. Then the two solver are seperated....
I am working on something similar and I came up with the same conclusion. Calculate the purely numerical graph first and log changed expressions to touch dependent features. Do document recompute and let features containing expression observers pull down the changed values. Not to highjack the thread, but here are a couple of pictures.

ExpressionGraph.png
ExpressionsDialog.png
Well this looks quite advanced stuff. Anyway i sincerely hope FreeCAD will have this capabilities in the future. I hope you the devs figure everything out in the end and this feature matures in FreeCAD.
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Spreadsheet module

Post by yorik »

jriegel wrote:Another option is to use the spreadsheet like a dialog. Only solve it if its "open" and save to the document if the user click Ok or Cancle. Then the two solver are seperated....
Interesting, there could indeed be a "solve" button on the spreadsheet, so nothing automatic. Basically it would be the same as changing the values of some properties manually...

But i think tanderson's stuff is really more powerful... And looks much simlper to use, probably a much better track to follow
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Spreadsheet module

Post by triplus »

Any solution that will do the job is great. On the long run i do see benefits of having this feature in Spreadsheet Module instead of using standalone dialogue but any solution that does the job will do. Adding "Update Button" is sensible thing to do by itself because in the future more complex scenarios will be used and user will probably want to set everything up and then invoke document solver to do its job instead of doing intermediate steps.
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Spreadsheet module

Post by jmaustpc »

tanderson69 wrote:I am working on something similar and I came up with the same conclusion.
Hi Tanderson69
Could I have a look at what you've done? Is your code development at a point where testing would be useful or appropriate? If so have you pushed a public branch somewhere with this code? :)

Jim
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: Spreadsheet module

Post by tanderson69 »

jmaustpc wrote:If so have you pushed a public branch somewhere with this code?
hello jim, I created a separate forum thread. viewtopic.php?f=10&t=6354
Post Reply