Any news on a graphics system?

[odiferousmint]

Hello. Is it planned for anytime soon? Is https://www.atronixengineering.com/downloads the best choice if one wants Rebel 3 with GUI? :/

[Oldes]

Hi.. I'm now busy with a non Rebol related project. Then I would like to finish the merge with the crypt branch.

For which os you want the gui? There is already something done for Windows.

[Oldes]

The Atronix version is dead now.

[odiferousmint]

For which os you want the gui? There is already something done for Windows.

Linux (64-bit).

[Oldes]

What kind of Linux? Gnome, KDE, Xfce?

[odiferousmint]

I do not use a desktop environment, only a window manager. I did try atronix-rebol-linux-64bit's Demo out, it looked fairly okay. I have no idea how customizable it is though. The most important bit is that it worked!

[odiferousmint]

Under Ubuntu:

[Oldes]

@odiferousmint yes... and?

My branch is still mergeable direct continuation of the community version, which never had a View support and unfortunately has no active members anymore.

Saphirion's version was initially closed source and when you look what is public now, there is still only the Windows' native code.

Atronix's version was somehow based on Saphirion, but the last version is again uncomplete and so unbuildable.
Both versions were using AGG, which is a dead end, because the initial author died years ago. Atronix than moved to SKIA - that is the missing part of their sources. They also tried to use SDL, which I supposed to be an unnecessary layer.

Anyway, even with the time-machine (using some older version of Atronix sources), it would be unmergeable and using their code directly, you will get as a bonus all the issues which I tried to resolve during last few years (currently 323 left versus 1501).

But I'm of course interested in having a GUI, but to be honest, my priorities are still in CLI.

And I'm still undecided, if

• I should go the native GUI route as Red did (which requires deep understanding of each system = a lot of work)
• or integrate a Bland2D (as a much faster 2D drawing engine than AGG) - already have something done.
• or somehow use 3D engine like cross platform Sokol and so use the power of current GPUs

[Oldes]

Before continuation on GUI, I would really like to have implemented a struct! datatype! There already is something done, but it still needs improvements to be more useable.

[odiferousmint]

Before continuation on GUI, I would really like to have implemented a struct! datatype! There already is something done, but it still needs improvements to be more useable.

That looks good, I am looking forward to the struct! datatype as well.

To be honest I do not miss GUI from Rebol that much. Perhaps I will stick to Tcl/Tk or Erlang + wxWidgets because the rest (such as Electron) are bloated to oblivion. In all fairness I do want a stable Rebol 3 before GUI. :) In fact, I could do without the GUI bit.

I think I will close this as my questions have been answered. Thank you!

[henrikmk]

I should go the native GUI route as Red did (which requires deep understanding of each system = a lot of work)

My two cents, as a Saphirion developer, who daily works with R2:

Don't go the native GUI route. You give up a lot of flexibility, and it looks to me that the Red guys are being hindered in progress, because of the native UI element limitations between different OSes.

You might also be thinking that you then don't have to implement buttons, checkboxes, etc., but in fact, those things are quite easy to implement via a widget description system, like STYLIZE in R2. Widgets will also become completely identical across OSes, and your testing requirements will be much reduced.

We know this already from R2 VID.

Carl's R3 VID honestly never turned out very good, and it would be necessary to start over. I was there, when it was designed, and we struggled a lot to come up with something good, particularly, because GOBs were not abstracted properly at first, and then the abstraction became too simple. Then a hopelessly bad GUI resizing engine was added. Then months of work was spent by Saphirion developers on trying to improve said resizing engine.

It didn't work out, and the design is inferior to the old REBOL/View 2.x.

We already have a very deep understanding of native REBOL/View to draw deep experience from. In fact REBOL/View 2.x is a really good design with some very specific shortcomings that can be solved in R3, and I can go into detail on each one of them, if desired.

It makes sense, like R2 does, to split a GUI system in the upper widget/layout/resize level, and a lower View, GOB/Face and event level. The lower View level already exists in R3, as far as I understand.

In R2, VID is a dialect that is fused to the layout engine. In R3, it should rather be a small library of face tree manipulation and navigation functions. This makes it possible to build a sturdy VID dialect on top of that, and also GUI editors, widget descriptors and GUI navigators.

I can also go into more detail on building a function library, if desired.

[Oldes]

Hi @henrikmk , nice to see you here ;-)

I agree that It would be good to have identical GUI across all systems. I'm getting closer with small steps. For example I'm now able to use Blend2D powered draw on windows/osx/linux. The Blend2D extension can include some sort of GUI as well... my idea is to be able compile the draw dialect into widgets with defined input/output values... but probably first just some sort of binary draw input, which would be interpreted on the Blend2D side as it now interprets pure draw commands from the draw block.

But to have it cross-platform, there must be first done the root view part (like opening a window, event notification...) for osx and linux, because if it exists somewhere, I don't have it. The Saphirion sources are only with Windows support.

Anyway... I just included a simple GOB based GUI example in the repository. It is quite usable for small GUI application with some input fields and some buttons.

Meanwhile I'm also playing with an idea to have a HW powered GUI. For example I already have a prototype to start a Sokol powered window in a separate thread:

I can imagine that it would be possible to use well known imgui there... again with some sort of precompiled DSL, which would be interpreted on the native side. But the main question so far is, how to share events/commands between Rebol and the Sokol thread in the best way?

There is a lot of paths... but I'm alone :-)