source code

Usage of the framework, compiler and tools

Re: source code

Postby rochus » Sun Dec 13, 2020 9:26 am

There are several alternatives how to integrate with Qt. For example, in my version of the Oberon System ( I simply replaced "Oberon.Loop" by callbacks from the Qt window in which the Oberon system operates. In my Smalltalk-80 VMs ( its the other way round: the loop including scheduler and co-routine implementation were already written in Smalltalk and part of the virtual image, and the C++ or Lua version of the interpreter just call QApplication::processEvents; even the integrated IDE and debugger implemented in Qt don't have their own event loop but get their time slots from the Smalltalk VM. And all these design variants are fully platform independent; there is no platform dependent code in these projects and it's easy to build them on all platforms due to the qmake based build system.
Posts: 7
Joined: Sat Dec 12, 2020 1:15 pm

Re: source code

Postby adimetrius » Sun Dec 13, 2020 1:10 pm

When you say, 'Platform-dependent code in bbcb', are you referring to the Host subsystem? If so, then it's there by desing. There's no appetite for moving anything out of Host into the non-Host subsystems.

Well, at least for the most part ))
User avatar
Posts: 52
Joined: Sun Aug 04, 2019 1:02 pm

Re: source code

Postby rochus » Sun Dec 13, 2020 2:29 pm

I'm not yet familiar with the Blackbox implementation, just had a look at the code in "platform dependent" is each module whose implementation or API changes with the platform. In bbcp there seem to be quite many of these, accross many subsystems. It's a lot of work to implement and maintain those. bbcp seems to at least have managed to have a platform independent core and sort out features only available on Windows.
Posts: 7
Joined: Sat Dec 12, 2020 1:15 pm

Re: source code

Postby X512 » Mon Dec 14, 2020 1:02 am

Ivan Denisov wrote:As I remember, Peter Kushnir made analysis for compatibility of BlackBox with Qt several years ago. So he said, that this will not have positive outcome, because Qt works like framework with hidden internal loop with it's own garbage collector etc. And there is no access to lowlevel Qt framework mechanisms, so BlackBox is not possible to port with Qt.

It is actually possible to port BlackBox to Qt. Hidden internal loop is not an issue. I have managed to port BlackBox to Haiku operating system ( It has C++ only GUI API, hidden internal loops and mandatory separate threads for each window. I directly used mangled API functions and vtables from Haiku dynamic libraries and provide C++ compatible RTTI information. I added limited multi-threading support, so different threads can call BlackBox code, but only single thread can run inside safe BlackBox environment (controlled by mutex similar to GIL in Python). There are no BlackBox-managed main loop, OS callbacks call BlackBox code acquiring global mutex. See readme and source code in repository for details.
Posts: 58
Joined: Sat Feb 07, 2015 2:51 pm


Return to Common questions

Who is online

Users browsing this forum: No registered users and 1 guest