BCF Support GSoC Proposal

[pPodest]

https://www.bimcollab.com/en/developers/Developer-SDK

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.

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!

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.

[hardeeprai]

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.

[pPodest]

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

[pPodest]

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

[hardeeprai]

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.

[pPodest]

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.

[pPodest]

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!

[yorik]

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.

[pPodest]

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.

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

Thanks, I appreciate it!

[pPodest]

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