BCF Support GSoC Proposal

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Thu Jun 20, 2019 5:58 am

Hey Duncan, thank you for the link! The BCF-API is definitely worth a look :)
But before I dive into that I will concentrate on getting the frontend of the plugin (nonGUI as well as GUI part) up and working.
duncan.lithgow wrote:
Wed Jun 19, 2019 6:15 pm
So I can look into it if it's important. I think yorik might be right that it's not really used. But as I said, let me know if you want me to look into it.
Thank you very much, I appreciate it! As yorik already suggested, I am currently not putting that much focus on the bimSnippet topic. However, I will keep that in mind!
yorik wrote:
Wed Jun 19, 2019 6:23 pm
Next week is the first official GSOC partial review, I think there is not much specific to do on your side, since everything is going pretty well, but maybe we can take the opportunity to wrap things up a bit, this will do good for us too... I would concentrate on "finishing" and document what can be finished and documented, and leave the rest for the next phase. So we have a nice clean "state" now. How does that sound?
That sounds good. I then will start on the documentation of the data model and the reader and writer modules. Maybe also already write about the interface that shall provide access to the data model, although it is still in a rather volatile (I don't know if that is the best word for what I want to express) state.

One last question regarding the form in which I will write the documentation:
Do you mind if I write the documentation in latex? Or what form shall the documentation take on? Should it be already in the form of a wiki page?

Otherwise, have fun on the urban sketchers meeting. ;)
User avatar
hardeeprai
Posts: 164
Joined: Sun May 23, 2010 2:41 pm
Location: Ludhiana, Punjab, India
Contact:

Re: BCF Support GSoC Proposal

Postby hardeeprai » Fri Jun 21, 2019 10:29 am

pPodest wrote:
Thu Jun 20, 2019 5:58 am
One last question regarding the form in which I will write the documentation:
Do you mind if I write the documentation in latex? Or what form shall the documentation take on? Should it be already in the form of a wiki page?
Though I like LaTeX very much and work a lot with it. But, IMO, you can use .md (mark down) on Wiki.
--
H.S.Rai
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Fri Jun 21, 2019 11:48 am

Ok thank you for the feedback!
I also thought of just using this to start a wiki page on github for the plugin, which then also can be ported to the freecad wiki of course :)
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Fri Jun 21, 2019 3:26 pm

Hey,

as I said, I started a wiki page on github for the plugin. You can view it here. With it I intend to give everyone interested an introduction to the plugin, and how it operates under the hood. In addition to that I will update the Readme.md of the plugin repository with a little tutorial on how to use the plugin in its current state. That is reading in BCF files, modifying some parts and then writing it again.

Let me know what you think of the wiki page, as it is now :)
Last edited by pPodest on Sat Jun 22, 2019 2:28 pm, edited 1 time in total.
User avatar
hardeeprai
Posts: 164
Joined: Sun May 23, 2010 2:41 pm
Location: Ludhiana, Punjab, India
Contact:

Re: BCF Support GSoC Proposal

Postby hardeeprai » Fri Jun 21, 2019 4:47 pm

pPodest wrote:
Fri Jun 21, 2019 3:26 pm
I started a wiki page on github for the plugin. You can view it here. Wit it I intend to give everyone interested an introduction to the plugin, and how it operates under the hood. In addition to that I will update the Readme.md of the plugin repository with a little tutorial on how to use the plugin in its current state. That is reading in BCF files, modifying some parts and then writing it again.
Good beginning of documentation.
--
H.S.Rai
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Sat Jun 22, 2019 2:36 pm

So I have finished the wiki page on the part of the plugin that is finished now, which is the lowest layer of this graphic. The actual page that goes into detail about the Data Model Layer is BCF Package.

Also the landing page of the repo now sports a nice(r) README.md with a little tutorial on how to use the reader and writer modules to change the contents of a BCF File.

Tomorrow I will be taking a day off, however the dev-log will still be updated, even though it probably will be just composed of one line.
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Tue Jun 25, 2019 5:26 pm

I have been thinking the interface between the GUI and the data model over and over now and I am not getting to a satisfactory solution. Currently the situation is the following:

For future compatibility and more important maintainability and expandability, I want to make use of the Model-View paradigm that can be nicely implemented in a Qt application. Also, I want to support a nice programmatic interface. As my current understanding of the Model-View stuff in Qt is, is that I have to write a separate model to each view, not that big of a deal. The model is supposed to access the data model that is maintained in the background.

I can imagine two possibilities for integrating the GUI and the PI (Programmatic Interface for the nonGUI mode):
  1. write both, the model and the PI separately and access the data directly in both
  2. create a PI and access just it in the model classes of the GUI
ad. 1: this has the disadvantages of possibly duplicating code => maintainability decreases.
ad. 2: adds a additional layer between View and Data Model, the layers would then be: View <-> Model <-> PI <-> Data. This does not decrease maintainability that much but the expandability possibly takes a hit because this approach is not that easy to grasp and rather a lot code has to be written in many different places to add (let's say) support for a new element.

Do you have any suggestions on how what option would be preferable? Or do you even have a completely different approach in mind? If so please share!
User avatar
yorik
Site Admin
Posts: 11397
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: BCF Support GSoC Proposal

Postby yorik » Tue Jun 25, 2019 9:29 pm

Excellent work! I think this ends very nicely this first phase.

About latex, I have no strong opinion, after all, the idea of these languages is to be easy to translate into other formats.

Regarding the two possibilities above, my own instinct would be to go with a python interface first, then use that interface in the GUI (but for more fun, I would develop both side-by-side). However, this means you won't take full advantage of the data model provided by Qt. It will be a rather thin thing that basically manipulates your PI functions. If you want to play more with the Qt stuff, you might prefer the second option. Your choice.

That said, you already developed a data model. So in a sense, "mirroring" it in Qt would be just that, a kind of mirror.
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Wed Jun 26, 2019 5:37 am

I guess your suggestion to rather go with the second possibility while atm focusing on the PI (Programmatic Interface) is best. For a moment I thought of creating subclasses of the classes in the data model. These new subclasses would also implement QAbstractItemModel and be used as the models to the views.
But I dismissed this idea quite quickly after thinking about it. It would entail that, in case of a rollback (I will describe it below) I would have to replace every model object in every view of the GUI.


With rollback I mean replacing the current data model with a previous one. The data model, in the plugin, is completely contained inside a instance of type Project. Thus a rollback replaces the currently used object of Project with a previous one. Rollbacks might be used in the future for undo operations, or letting the user know that his change could not be applied and resetting to the erroneous state to let him or her fix it.
yorik wrote:
Tue Jun 25, 2019 9:29 pm
Excellent work! I think this ends very nicely this first phase.
Thanks, I appreciate it! :)
User avatar
pPodest
Posts: 70
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Fri Jun 28, 2019 12:27 pm

I wanted to let you know that from tomorrow on till Monday, I will be making a camping trip and not doing any development work. On Monday however I will be back again and working on pI.

To get up to speed on the current state of the project: I have created a new branch feature/PI_retrieval that has an updated README.md file. It explains how the plugin can be integrated into FreeCAD and how it can be used, but beware this will change in the near future, reasons are explained in the README.md file. I updated the dev-log just now, which also explains a bit what is possible with the plugin atm.

Cheers,
Patrick