Freecad? Has it been ported?

I was looking over the deps, looks straight forward except pivy.

If someone more knowledgeable can lok at this depa list, if haiku has the required livs, i may give it a go

https://wiki.freecadweb.org/Compile_on_Linux#Python_2_and_Qt4

Yes, I did looked at it.
The roadblock is : OpenGL support is disabled in Qt.

Ahoy !

I’m not a developer, I’ve just checked also FreeCAD availability from curiosity about a week ago, but honestly as I followed pivy and others on FreeCAD site I gave up to ask about, as I found some API etc. such it may not exist or should be corresponded to a Haiku API (if that possible at all).

Anyway, now I just write as If you want a recent version to build, you may consider THIS also :

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Building against Python 3 and Qt5

By default, FreeCAD 0.19 and earlier build for Python 2 and Qt4. Since these two packages are obsolete, it is better to build for Python 3 and Qt5. Support for Python 2 and Qt4 has been removed in FreeCAD 0.20 and it is not necessary to explicitly enable Qt5 and Python 3 if compiling the latest development versions.

In a modern Linux distribution you only need to provide two variables specifying the use of Qt5, and the path to the Python interpreter.

For 0.19:

cmake -DBUILD_QT5=ON -DPYTHON_EXECUTABLE=/usr/bin/python3 …/freecad-source

For 0.20_dev:

cmake …/freecad-source

Note that when switching between 0.19 and the 0.20 builds, it may be necessary to delete CMakeCache.txt prior to running cmake.

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

I copied here the whole section but of course I ment for the highlighted.

Again: OpenGL in Qt is not working on Haiku yet.

I’ll have to wait

so… did latest gcompris has same fate?

Given these news:
Mesa 21.0 is now working with Haiku for software OpenGL rendering – OSnews
This means we now have opengl support, so the issue is probably recompiling and some minor code changes in QT, but don’t take my word for it, I barely write code anymore :smile:

OpenGL is available since long on Haiku, but it is not that simple. Somebody have to implement support for OpenGL contexts in Qt. At least thats what 3DEyes told last time AFAIR.

What do you mean?
OpenGL contexts are native to QT since version 5.0
QOpenGLContext Class | Qt GUI 5.15.7

Do we need to build the latest version in Haiku?

Please start to work on it so we can port some useful programs, thanks.

2 Likes

That’s a tall order.
I haven’t used Haiku but I did love BeOS back in the day and I am going to work on some ports, but my time is limited.
So I can try, but no promises, I am already writing a document to do triple secure boot on my surface pro 4, which means I am in the process of doing the triple boot.

This will be refind + Windows + Arch + Haiku
This also means porting the surface kernel to Haiku:
GitHub - linux-surface/linux-surface: Linux Kernel for Surface Devices

What? Explain.

All computers have what’s called a BSP - a board support package.
Usually this will be register maps, drivers, firmware etc…
This is separate and installed on top of the OS, in any OS to allow the full functionality of the hardware such as graphics acceleration, camera, touchscreen, etc etc
And I do want free cad and 3D printing stuff and a decent browser so it means QT and the surface kernel for my machine

But how is this “porting to Haiku” ?

It will enable surface users to use the hardware fully of the Surface on Haiku.
Does it benefit Haiku per se? no.
Does it benefit the Microsoft Surface users and help some take the leap to Haiku? yes

But the whole reason people want an operating system is to run their applications, be it a browser, video editing software, audio editing, writing documents, watch movies, etc
But what is the point of an OS with limited hardware support? not much, it becomes underpowered

So you want to port the drivers to make Haiku fully usable on Surface hw?

That is my goal, I assume many of those exist already in Haiku.
But I don’t know Haiku’s driver discovery process.
These days most are on some sort of pci bus, sometimes you can’t see the correct PCI id’s.
Linux is great for this, I was doing some work on another OS - a real time OS to enable the network driver which was already there but it did not have the correct PCI ID in the code so it was a simple fix of adding it in.
It get’s tricky if you need to port drivers, I used to develop device drivers in linux so I am somewhat familiar with ioctl calls, etc
A good example of screen settings for the surface:
linux-surface/surface-4.19.config at master · linux-surface/linux-surface · GitHub
these are build flags to pull some sort of code

Good luck to your jurney.

I was considering it, I will probably start with the QT :smile:
it makes more sense to have the usable freecad and other apps than to have the extra features on the surface…

1 Like

Might make more sense to fix the qtopengl addons for qt 5+. Because it looks like a gpu driver is coming

As of qt5.9xxxx iirc they switched to a internal drawing system and offer a few render engines via spir-v, theres a qt vulkan backend to iirc

Not fresh on exactly what they have done last few years