FreeCAD for iPad?

[Kunda1]

oooh.. i like where this is going

[elgambitero]

So I’ve been looking into this further... just, for fun.

Module Overview

I took a look into the FreeCAD documentation on source code, specifically on the description of the source code, and there are some phrases that actually caught my attention, I drew conclusions from them, if any of you is familiar with the codebase maybe you can confirm or correct me:

• “FreeCAD is separated in two different parts, named App and Gui [...] App contains all the functionallity that needs to run in pure console mode (no GUI. As FreeCAD can be compiled without it’s GUI.”
  
  I understand then that, a good starting point may be to translate App, and try to get FreeCAD-swift to run in CLI and maybe somehow test if it works the same. It’s cool because at this stage, you don’t need XCode yet.

• “Most of FreeCAD's functionality is implemented in Modules. FreeCAD without its module is a simple container window that can just open and save a file”
  
  Maybe an even better starting point! App can be translated into swift, and compiled, and the most basic functionallity can be tested just to verify that the used ported strategy (whatever it is) works.

• “Most modules that use solid geometry depend on the Part module”
  
  I’m gonna be honest with you guys... Despite FreeCAD being a much bigger project, I am currently only interested in Part Design. (And maybe techdraw). So I understand that my dream goal would be to have that working, and that may imply: Part + PartDesign + Sketcher.

• “Modules are always initialized from Python.”
  
  So let’s change that. For each module, one would have to locate all entrypoints and make the same wrapper, but with swift. Every Python class may be translated to swift that way.

• “OpenCascade is used to create and manage all the solid geometry of FreeCAD, while coin3D is used to manage the 3D view. OpenCascade is used mainly in the App world, and coin3D exclusively in the Gui world.”
  
  OK this is a tough one... OpenCascade is C++ so I understand that, as FreeCAD is linked via C++ to OpenCascade, that would not be a problem. Coin3D on the other hand... relies on OpenGL to render and OpenGL is not available in iPadOS. So code reuse is kinda bad here. (But I expected GUI to be a hard roadblock.)

• “Standard geometrical objects, such as those found in Part or PartDesign, have their OpenCascade-based geometry defined in their App counterpart, while the Gui counterpart (also usually called "View Provider") is responsible for creating a coin3D representation of that geometry”
  
  I understand that whatever class there is on Python to hold the Documents, a Swift counterpart may be made.

• I also see, by the description of the code folders:
  
  “ The basic directory structure of the source code is organized like this:
  * App: contains the FreeCAD console-mode application, defines basic structures and base classes for document objects, that are used by modules to build their own.
  * Base: contains core functionality commonly used everywhere in FreeCAD: 3D vectors, units, matrices, placements, etc.”
  
  So maybe by translating App and Base, a CLI proof of concept CAN be tried...

A peek in the code

So, I cloned the repo, checked out to the 0.18.4 branch just to pick the most established version, and took an innocent look at the code. Most specifically the App and Base modules.

App has 141 files and Base has 152 files:

• Around 4 files by class and I see...

• for every class there is a file ended in PyCCX.cpp and PyImp.cpp. I assume those are the wrappers.

• there is a Py.xml that apparently is used to create the C++ header, that pretty much exposes the interface of each Python class...

A proof of concept

So!

I am starting to see the shape of a plan for a proof of concept: Translating App and Base modules to swift bound code. The way to do this would be:

• Create swift classes that would correspond to the interfaces described in Py.xml (careful with types!)

• Create C wrappers for the C++ classes, whose methods will be called by the swift classes (it’s messy I know, but C++ swift interoperability just works that way...)

• Think of a way of comparing a Python based App + Base CLI FreeCAD to the swift based App + Base CLI FreeCAD. Just to see if there is equivalence.

If any of you is familiar with the codebase I’d love that you chime in and confirm/correct these ideas. If I made you roll your eyes with any blatant misconception, I am sorry.

What do you guys think?

[Kunda1]

This is a good start. I have a meta-comment

I would recommend to use a little bit more formatting in your posts. Like using headers and italics and emphasis that way the post doesn't read like a wall of text and is easy to follow. My experience on the forum shows that information presented in a post really impacts collaboration.

[elgambitero]

I was actually thinking the same thing... but I struggled with tags... let me see if I can edit it or repost it with humane formatting.

Edit: gave it a shot! Hope is more readable now!

[elgambitero]

I’ve been looking into this thing further, and it really seems like the main roadblock would be the UI.

The way I understand FreeCAD’s UI, (idk if I am getting this right):

• the window, toolbars,general UI, etc. is made in QT5 with python bindings.

• The 3d representation is carried out by pivy, a python binding for Coin3D.

As DeepSOIC said, there is qt5 bindings for swift apparently, but what about Coin?
It has no swift bindings, and quarter, the qt binding for Coin seems to only work with Qt4...

How would Coin be called from a swift world?

[ajoeiam]

It may sound like a gimmick... but ipad is quickly becoming a rival to MS Surface. It now supports a mouse.

phpBB [video]

so... Qt for iOs is a thing... maybe, just maybe...

Dunno - - - - I find that I'm struggling using multiple 1920 x 1080 monitors.
I'm wanting to add a 3840 x 2160 monitor - - - - for easier and more usable screen real estate.

How confining myself to a 10 or 12" monitor is going to improve things - - - please explain?

[elgambitero]

It may sound like a gimmick... but ipad is quickly becoming a rival to MS Surface. It now supports a mouse.

phpBB [video]

so... Qt for iOs is a thing... maybe, just maybe...

Dunno - - - - I find that I'm struggling using multiple 1920 x 1080 monitors.
I'm wanting to add a 3840 x 2160 monitor - - - - for easier and more usable screen real estate.

How confining myself to a 10 or 12" monitor is going to improve things - - - please explain?

It’s not just the screen. It’s all about touch controls and, if you can, a pencil.

I tried Shapr3d with apple pencil and touch controls and it just felt right. Touching the commands on the screen and then operating on the part with the pencil feels organic, like when you are drawing on a piece of paper. (But shapr is not a good option because it has no operation history)

Also, for me there is portability. COVID got me working on remote, and having FreeCAD *everywhere* would be great. One simply does not know when the inspiration is gonna hit.

[ajoeiam]

It may sound like a gimmick... but ipad is quickly becoming a rival to MS Surface. It now supports a mouse.

phpBB [video]

so... Qt for iOs is a thing... maybe, just maybe...

Dunno - - - - I find that I'm struggling using multiple 1920 x 1080 monitors.
I'm wanting to add a 3840 x 2160 monitor - - - - for easier and more usable screen real estate.

How confining myself to a 10 or 12" monitor is going to improve things - - - please explain?

It’s not just the screen. It’s all about touch controls and, if you can, a pencil.

I tried Shapr3d with apple pencil and touch controls and it just felt right. Touching the commands on the screen and then operating on the part with the pencil feels organic, like when you are drawing on a piece of paper. (But shapr is not a good option because it has no operation history)

Also, for me there is portability. COVID got me working on remote, and having FreeCAD *everywhere* would be great. One simply does not know when the inspiration is gonna hit.

With your "everywhere" in mind I would suggest getting into voice commands and 'smart' phone watches.

[elgambitero]

I have been thinking about this further, and I see that porting FreeCAD to iPad is not a just a port, it implies porting FreeCAD to Swift. A major codebase transition. And the size of such project pretty much calls for a community approach. (Keeping both massive branches would be inneficient and divisive for the community).

But the case can be made for a such a major transition, as long as the roadmap ensures that the codebase change benefits the Free Software community as a whole, and the resulting work is usable along the same platforms.

In this humble post, I will try to make such case:

The case for a transition from Python to Swift

The requisites for a roadmap that respects freedom, open source commuinty work, and benefits the project could have this shape, and I think Swift pretty much covers it:

Free software toolchians

Swift can be frowned upon because it is created within Apple (Quite a remarkable freedom offender). And there could be the sentiment that Swift is yet another iThing, but thats oddly not the case .

The compiler and the language itself is Free Software with Apache 2.0 license, which is compatible with GPL3.0. It does have a library exclusion clause, but that just releases the user from the obligation of mentioning the compiler in the attributions.

Swift is avaliable for use in Linux, Windows and MacOS. In linux, I have not seen any distro incorporate the Swift toolchain in their package manager, but the adoption may be coming in the near future.

Interoperability with C++

This one is tricky, but approachable. And with good future perspectives.

FreeCAD’s optimized codebase is in C++, which at the time has no direct interoperability with Swift. It would work by making interfaces in C.

A criticisim of this is that, because of C++ being OOPL and C not being OOPL, this results in unsafe pointer handling from swift in order to handle the C++ classes. Not ideal, but still works.

There are active developments on developing interoperabilty between C++ and Swift. Not ready at the moment. Given the interest in that to happen by major agents in the industry, that may very well end up happening. There are declared intentions in Swift’s repository: https://github.com/apple/swift/blob/mai ... nifesto.md

Interpreter, for macros an CLI usage

Despite being a compiled language, Swift does have a REPL interpreter, that may work as good as the python interpreter bundled within FreeCAD. (You can even import modules in the same python fashion)
The REPL may be included into FreeCAD’s workflow.

Modularity

FreeCAD is famously organized in a modular fashion, so much so that FreeCAD can be used as a module in any other program by importing it as a module with

Code: Select all

import FreeCAD

Swift is organized in a similar modular fashion, with the possibility of declaring packages and importing them in the same fashion.

Swift has REPL support for swift packages, which makes it a perfect Python substitute.

Benefits of a Swift codebase

Better type organisation

Porting the python classes to swift pretty much involves structural changes despite keeping the class structure intact, because of the soft typing practices in Python.

But Swift’s generic and associated typing provides just the right amount of flexibility that Python provides for FreeCAD

Less error prone code

Swift is built in such a way that, things like dereferencing a null pointer, or assigning the wrong type cannot happen. In Swift, if your code is prone to create and unhandled exception it will simply not compile.

Less overhead, faster code

As FreeCAD approaches maturity, more people choose it for bigger projects, because it has become quite a valid option. In those occasions, its limits show.

The Python virtual machine limits the scalability of projects, eventual optimization of programs (as it cannot use multicore), and it adds an overhead that pretty much bars it from being implemented into mobile computers. Swift is compiled, allows multicore, and when compared with C, it runs only 4 times slower.


So there it is. For me, making a proof of concept by porting a testable portion of the CLI part of FreeCAD sound like a cool project. But the case can be made for a bigger approach, and I think it is interesting to think about.
I wish I had a clearer vision about FreeCAD’s current development roadmap so I could post a more sensible case, but I still think that the infrastructure for such a thing is already working.
iPad would come further along the roadmap, if ever... and it would be mostly a GUI problem.

What do you guys think?

[freedman]

I can't help with code but I will say that every kid I know has an IPad. Every teen I know seems to play on game players but not on IPads much anymore. Most teens are working their way to a tablet. I don't what FreeCAD solid modeling age group is 16-100...

The last time I saw development books for an apple product it was 13 volumes, they are specific about everything.