Smalltalk › Pharo › Pharo Smalltalk Developers

Pharo8: Advance on Spec2 and Gtk3 backend

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

EstebanLM

Pharo8: Advance on Spec2 and Gtk3 backend

Hi,

Last couple of months I have been really busy moving forward (along with Cyril and Pablo, in different places of the roadmap) what will be the backbone of Pharo 8.0 tool development: Spec 2.

I worked in a lot of things and somehow the weekly reports went missing (my mistake).

Now I’m going on holidays but I will take this week to announce/release/show what I have done latest weeks (then it does not accumulates so much and resuming the weekly report when I’m back will be smoother).

Anyway, this is the status of this parts:

1) Spec 2 has move into a less immature status, and we are arriving to a status of “internal beta” soon. For “internal beta” means the features we wanted to implement are there even if still with bugs and miss-behaviours).

For this, in (very) short summary we passed through:

- We made a pass on all Spec components and we deprecated some and added some others.

- We introduced the concept of “transmission”, to partially mimic what glamour was capable of doing in a very easy way.

- We introduced 5 different layouts to replace the unique “do-it-all” older.

- We introduced the concept “Application” to handle window flow and application resources.

And all this was already announced, but we have moved to a more stable phase now and this is ready to be stressed.

Last version of this is already integrated on Pharo 8 (we renamed the prefix to Sp, so we avoid part of the migration pain).

Other point where there was a lot of movement was in the Gtk3 backend.

Work has been done for stability that will affect (positively) all the system, not just backend: for example in UFFI I needed to introduce the concept of NULL and the possibility to “cast” numeric declarations.

This is because in 64bit NULL != 0 (being 6 an int32), and because 0 != 0L (and many like that).

So now you can have ffi invocations of the form:

self ffiCall: #(void myFunction (NULL, (long)42)).

And this will be correctly parsed on the different platforms.

But overall, the Gtk3 backend is also in good shape and we will put it to be tested soon(™) :P (I estimated it was last week, but as always there were complications).

One thing I think is interesting to talk about (because we needed to change a lot of things to make it work, much more than was expected at first) was one Gtk element that you will find interesting: GtkMorphView.

Basically GtkMorphView allows you to put a morph (whatever you want) into a Gtk container (the Spec component to allow this is SpMorphPresenter). This allows you to do things like this:

And as I said to Stef last week: I find this screenshot very sexy because what is showing is 4 simple button morphs behaving in sync with other Gtk3 components in an external window.

The consequences of this are obvious: we can, if we need it, fallback to morphic if you need to do something the backend does not allows (Roassal, I talking about you).

Of course, since this is our final target, there is a BlocPresenter also on the works.

I’m sure Pavel can share some sexier screenshots of what he is doing with this.

A fun fact, that drives me to the next step is this: The GtkMorphView was working smoothly in windows but crashing immediately in macOS (I found it fun because is usually the opposite).

I needed to make a “stop the world” and jump to work on it and it tooks a couple of weeks to just figure out what was happening (debugging this kind of things is always hard). And at the end I had an approximate guess: The problem was in a not-thread safe way to handle the display in the VM side.

I took a breath to decide the solution and at the end I decided to take the easiest path but maybe more time consuming at the beginning: Since we are going to move to a “headless” vm (which means do not initiate a display at all, unless demanded and through the image), I did not see the point on jump and fix a code very hard to understand and debug.

Instead, we moved at the top of the backlog the “move to headless vm” and Pablo and me started to work on that.

Now, there are problems associated to that (like event loops and that)… but this is not anymore Spec2+Gtk3 and then it requires a new mail to be explained :)

Esteban

EstebanLM

Re: Pharo8: Advance on Spec2 and Gtk3 backend

> On 1 Jul 2019, at 18:44, Alexandre Bergel <[hidden email]> wrote:
>
> Hi!
>
> Thanks for this wonderful effort!
>
>> The consequences of this are obvious: we can, if we need it, fallback to morphic if you need to do something the backend does not allows (Roassal, I talking about you).
>
> Why would you need to fallback to Morphic if you wish to use Roassal3?

I don’t.
My idea is that you will be able to fallback to Bloc or to plain Athens as you need.
Morphic was just the first component.

Also, I imagine someone who has already something made an investment in morphic (like someone using Roassal2 extensively).
Then he will be able to benefit of it too.

> Believe me, we will put the necessary resources to have R3 working very smoothly with Gtk. As soon as you feel confident for us to play with, then we will focus on this.

Oh, I believe you :)

Esteban

>
> Enjoy your well-deserved holidays!
>
> Cheers,
> Alexandre
>

Pierce Ng-3

Re: Pharo8: Advance on Spec2 and Gtk3 backend

In reply to this post by EstebanLM

On Mon, Jul 01, 2019 at 05:58:17PM +0200, Esteban Lorenzano wrote:
> But overall, the Gtk3 backend is also in good shape and we will put it
>
> Instead, we moved at the top of the backlog the “move to headless vm”
> and Pablo and me started to work on that.
>
> Now, there are problems associated to that (like event loops and
> that)… but this is not anymore Spec2+Gtk3 and then it requires a new
> mail to be explained :)

Very exciting. Looking forward to it.

Early this year I played with IUP using Pharo 7. Got as far as putting
up a hello world dialog but the overall behaviour was wonky, which I
imagined is due to event loops and such on the non-headless VM.

IUP => http://webserver2.tecgraf.puc-rio.br/iup/
IUPCocoa => https://github.com/ewmailing/IupCocoa

Pierce

ducasse

Re: Pharo8: Advance on Spec2 and Gtk3 backend

Hi pierce

we would be interested in knowing if the new infrastructure (FFI) you have better success.
If you want to give a try contact Pablo Tesone <[hidden email]>

Because we believe that the infrastructure we are putting in place for GTK can be reuse/extended
for other projects.

Stef

> On 2 Jul 2019, at 09:11, Pierce Ng <[hidden email]> wrote:
>
> On Mon, Jul 01, 2019 at 05:58:17PM +0200, Esteban Lorenzano wrote:
>> But overall, the Gtk3 backend is also in good shape and we will put it
>>
>> Instead, we moved at the top of the backlog the “move to headless vm”
>> and Pablo and me started to work on that.
>>
>> Now, there are problems associated to that (like event loops and
>> that)… but this is not anymore Spec2+Gtk3 and then it requires a new
>> mail to be explained :)
>
> Very exciting. Looking forward to it.
>
> Early this year I played with IUP using Pharo 7. Got as far as putting
> up a hello world dialog but the overall behaviour was wonky, which I
> imagined is due to event loops and such on the non-headless VM.
>
> IUP => http://webserver2.tecgraf.puc-rio.br/iup/
> IUPCocoa => https://github.com/ewmailing/IupCocoa
>
> Pierce
>

Pierce Ng-3

Re: Pharo8: Advance on Spec2 and Gtk3 backend

On Tue, Jul 02, 2019 at 09:29:01AM +0900, ducasse wrote:
> we would be interested in knowing if the new infrastructure (FFI) you have better success.
> If you want to give a try contact Pablo Tesone <[hidden email]>
>
> Because we believe that the infrastructure we are putting in place for GTK can be reuse/extended
> for other projects.

Hi Stef. Will do.

Pierce