BlackBox Framework Center

Zinn wrote:there is a big misunderstanding.

I agree with Helmut. There is some terminology mess.

I changed the topic to: "Basic in/out console functionality"

This functionality can be used for:
1. Debugging
2. Cross-platform console applications
3. To hide some errors logging for GUI applications
...

Ivan Denisov wrote:Why platform specific code is bad? Platform specific code in the System makes harder to run BlackBox in multiple platforms. The process of this splitting is called "hermetization of abstract layer". If you put any platform dependent code in the abstraction layer this is called "leaking of the abstraction layer".

Time flies, comrades:

Vitor Mikaelson noticed that the latest build lets you restrict the installation of applications built using the Win32 API.

Multi-platform Blackbox prototype is made with SDL basis some years ago and I have to say that hermetization is an only way to reach a goal.

Ivan Denisov wrote:Josef, please give the honest answer. Do you understand why Fonts and HostFonts are split?

I have now tried to answer this question and put together a
little wiki article because this is a non-trivial question and the answer is not
as obvious as one might expect.

See https://wiki.blackboxframework.org/inde ... separation.

Regarding the portability argument, I think we agree that technically there
is no difference at all. You don't have to link Console. This is the same as with Kernel.
You also don't link Kernel if you want your console app to be portable.

- Josef

Josef,

be more complicate if

=> be more complicated if

Good article!

Josef Templ wrote:I have now tried to answer this question and put together...

In short words the answer is "they split to prevent circular import". That is only one side, so the answer is not full.

For example Files hasn't import other System modules except Kernel, however it is also split for abstract layer and realization layer. This allows to replace realization even "on the fly".

The only module in System which has WinApi except Kernel is XYplane. It "is provided for compatibility with the book "Programming in Oberon" by Reiser/Wirth. ... It is not recommended for use in production programs."

The name Host is meaningful. It means that this folder depends on the host OS. It can be Linux, Windows, Mac etc. If we add some functionality for writing things to console (more general to stdout) this functionality should be cross-platform and consist of two parts: abstract layer and realization for the current platform.

This will allow the developers for other platforms (me, Alexander, Igor, ...) to make the realization for other platforms. And the software developed once will run in multiple platforms even without been recompiled. The StdLoader will load the realization for the interface from the Host folder. And for Windows the WinApi will be used to read and write data to terminal or a file, for Linux it will be libc library for read and write data to console or a file.

Before we add any new module for Linux integration, we have to discuss which way to go. First we need an overview which Linux versions are exist.

There exist an implementation based on SDL.
Another implementation based on Gnome.

I read in Docu of the Gnome version:
Another interesting aspect is that Gtk+ is available for Windows. If this would be efficient enough, then only one set of Host modules would be needed for Linux and Windows.

I am getting lost in the many Linux versions and I don't know which way to go.
- Helmut

Zinn wrote:Before we add any new module for Linux integration, we have to discuss which way to go. First we need an overview which Linux versions are exist.

There exist an implementation based on SDL.
Another implementation based on Gnome.

I read in Docu of the Gnome version:
Another interesting aspect is that Gtk+ is available for Windows. If this would be efficient enough, then only one set of Host modules would be needed for Linux and Windows.

I am getting lost in the many Linux versions and I don't know which way to go.

This Console module is not for Linux integration, but for Windows command line. In Linux is possible to replace the realization and the same interface will work with Unix Terminal.

SDL version was not completed by Ivan K. because of the alignment problem during calling of some SDL2 functions. Now this problem is resolved, however it seems that Ivan K. pause the development for some time. Anyway his experience is very interesting, and I am using it to develop cross-platform applications based on BlackBox now. I hope that Ivan K. will find some time to translate his notes about BlackBox hermetization to English.

The Blackbox for Linux was published by Oberon microsystems 3 years ago: http://www.inr.ac.ru/~blackbox/rsrc/bla ... letter.txt
Before this publication the Linux prototype from Oberon microsystems was available for several developers in Russia. OberonCore team makes their Console version of Linux BlackBox based in this prototype. Independently Igor A. Dehtyarenko made big work to sync this prototype with Gtk2 & Pango. Also later he developed native linkers for OpenBSD/FreeBSD & GNU/Linux.
With Alexander V. Shiryaev we made the project BlackBox Freenix: http://gitlab.molpit.org/blackbox/freenix
Yesterday I moved it to GitHub because I am planning to do some video tutorial about OpenGL cross-platform apps:

https://github.com/bbcb/freenix

I am syncing it with the Center version and building the Debian packages.
This is the current version of BlackBox Component Builder version for Ubuntu.

Ivan Denisov wrote:

Josef Templ wrote:I have now tried to answer this question and put together...

In short words the answer is "they split to prevent circular import". That is only one side, so the answer is not full.

For example Files hasn't import other System modules except Kernel, however it is also split for abstract layer and realization layer. This allows to replace realization even "on the fly".

The split of Files allows for (almost) ANY implementation, even one that needs to import other basic modules.
For MacOS or other platforms this gives you more flexibility in the implementation of HostFiles
without changing the 'System' architecture.
If you need, for example, to use mapped strings for user dialogs, you would need
to import Dialog. Under Windows, this is done by the common controls internally,
so you don't need to import Dialog.

- Josef

Josef Templ wrote:... this gives you more flexibility in the implementation ...

I think that the same flexibility is necessary for console input & output.

Ivan Denisov wrote:

Josef Templ wrote:... this gives you more flexibility in the implementation ...

I think that the same flexibility is necessary for console input & output.

For Console being useful even for Kernel logging it is not possible to have that.
Low-level logging is a MUST HAVE feature of Console, no matter
what additional features it provides. This was the starting point of my Console module.

- Josef