Smalltalk › Pharo › Pharo Smalltalk Users

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Peter Kenny

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

+1 to Norbert. In particular, does it mean that, from Pharo 8, we will be *required* to install Gtk3 backend to use Pharo?

Peter Kenny

From: Pharo-users <[hidden email]> On Behalf Of Norbert Hartl
Sent: 18 April 2019 11:58
To: Pharo users users <[hidden email]>
Cc: Pharo Dev <[hidden email]>
Subject: Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

Great!

Can you explain what is there, what somebody can load and what to expect. And even more important: what not to expect?

I don’t get any of the essential details from this mail.

Norbert

Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <[hidden email]>:

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced:

We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings!

Why we want a Spec 2.0 with different backends?

There are reasons that converged to decide us to make it:

First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic).
Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons:
Because there is still an important place for desktop applications market and most medium-size to big business still require them.
Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it).

For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come.

Why Gtk3?

There are some other important players in the "native widgets scene", so why we choose Gtk3?

Again, several reasons were taken into account:

Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too.
It is very mature and popular.
It is made in plain C.

Next step: tool migration

The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them:

Old GT tools will be replaced by new Spec tools (while preserving its power).
Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings.

And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :)

A small screenshot of the new Inspector (WIP):

<Screenshot 2019-04-18 at 12.07.16.png>

Esteban

EstebanLM

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

On 18 Apr 2019, at 13:08, PBKResearch <[hidden email]> wrote:

+1 to Norbert. In particular, does it mean that, from Pharo 8, we will be *required* to install Gtk3 backend to use Pharo?

For now is in early development so there is no easy way to install (since there are things to replace/fix in current image).

We will provide an install script soon (or maybe a prepared image, while we arrive to have a reliable baseline).

And no, you will not need it. Gtk3 bindings are an extra. If you want to do a desktop application (for example Schmidt is doing it), maybe you will want to install it. Otherwise you will continue as before.

And to be clear: Pharo 8 WILL NOT be a Gtk3 application.

Even if eventually the IDE will be able to run with it (since it will be a Spec 2.0 based IDE), there are a lot of huge things that need to be migrated before (and the GTInspector is not big: Calypso is).

And still then (maybe in Pharo 9), running with Gtk3 will be a choice.

Esteban

Peter Kenny

From: Pharo-users <[hidden email]> On Behalf Of Norbert Hartl
Sent: 18 April 2019 11:58
To: Pharo users users <[hidden email]>
Cc: Pharo Dev <[hidden email]>
Subject: Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

Great!

Can you explain what is there, what somebody can load and what to expect. And even more important: what not to expect?

I don’t get any of the essential details from this mail.

Norbert

Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <[hidden email]>:

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced:

We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings!

Why we want a Spec 2.0 with different backends?

There are reasons that converged to decide us to make it:

First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic).
Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons:
Because there is still an important place for desktop applications market and most medium-size to big business still require them.
Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it).

For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come.

Why Gtk3?

There are some other important players in the "native widgets scene", so why we choose Gtk3?

Again, several reasons were taken into account:

Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too.
It is very mature and popular.
It is made in plain C.

Next step: tool migration

The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them:

Old GT tools will be replaced by new Spec tools (while preserving its power).
Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings.

And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :)

A small screenshot of the new Inspector (WIP):

<Screenshot 2019-04-18 at 12.07.16.png>

Esteban

Ronie Salgado

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

That looks very cool

For the text editor are you using GtkSourceView or something else?

Greetings,

Ronie

El jue., 18 abr. 2019 a las 7:23, Esteban Lorenzano (<[hidden email]>) escribió:

On 18 Apr 2019, at 13:08, PBKResearch <[hidden email]> wrote:

+1 to Norbert. In particular, does it mean that, from Pharo 8, we will be *required* to install Gtk3 backend to use Pharo?

For now is in early development so there is no easy way to install (since there are things to replace/fix in current image).
We will provide an install script soon (or maybe a prepared image, while we arrive to have a reliable baseline).

And no, you will not need it. Gtk3 bindings are an extra. If you want to do a desktop application (for example Schmidt is doing it), maybe you will want to install it. Otherwise you will continue as before.

And to be clear: Pharo 8 WILL NOT be a Gtk3 application.
Even if eventually the IDE will be able to run with it (since it will be a Spec 2.0 based IDE), there are a lot of huge things that need to be migrated before (and the GTInspector is not big: Calypso is).
And still then (maybe in Pharo 9), running with Gtk3 will be a choice.

Esteban

Peter Kenny

From: Pharo-users <[hidden email]> On Behalf Of Norbert Hartl
Sent: 18 April 2019 11:58
To: Pharo users users <[hidden email]>
Cc: Pharo Dev <[hidden email]>
Subject: Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

Great!

Can you explain what is there, what somebody can load and what to expect. And even more important: what not to expect?

I don’t get any of the essential details from this mail.

Norbert

Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <[hidden email]>:

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced:

We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings!

Why we want a Spec 2.0 with different backends?

There are reasons that converged to decide us to make it:

First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic).
Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons:
Because there is still an important place for desktop applications market and most medium-size to big business still require them.
Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it).

For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come.

Why Gtk3?

There are some other important players in the "native widgets scene", so why we choose Gtk3?

Again, several reasons were taken into account:

Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too.
It is very mature and popular.
It is made in plain C.

Next step: tool migration

The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them:

Old GT tools will be replaced by new Spec tools (while preserving its power).
Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings.

And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :)

A small screenshot of the new Inspector (WIP):

<Screenshot 2019-04-18 at 12.07.16.png>

Esteban

EstebanLM

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

Hi Ronie,

On 18 Apr 2019, at 18:56, Ronie Salgado <[hidden email]> wrote:

That looks very cool

For the text editor are you using GtkSourceView or something else?

For now, we are using a plain GtkTextView but we will switch to GtkSourceView later (just because it provides some functionality like adornments for breakpoints and that the I do not want to do myself, even if it would be possible).

Esteban

Greetings,
Ronie

El jue., 18 abr. 2019 a las 7:23, Esteban Lorenzano (<[hidden email]>) escribió:

On 18 Apr 2019, at 13:08, PBKResearch <[hidden email]> wrote:

+1 to Norbert. In particular, does it mean that, from Pharo 8, we will be *required* to install Gtk3 backend to use Pharo?

For now is in early development so there is no easy way to install (since there are things to replace/fix in current image).
We will provide an install script soon (or maybe a prepared image, while we arrive to have a reliable baseline).

And no, you will not need it. Gtk3 bindings are an extra. If you want to do a desktop application (for example Schmidt is doing it), maybe you will want to install it. Otherwise you will continue as before.

And to be clear: Pharo 8 WILL NOT be a Gtk3 application.
Even if eventually the IDE will be able to run with it (since it will be a Spec 2.0 based IDE), there are a lot of huge things that need to be migrated before (and the GTInspector is not big: Calypso is).
And still then (maybe in Pharo 9), running with Gtk3 will be a choice.

Esteban

Peter Kenny

From: Pharo-users <[hidden email]> On Behalf Of Norbert Hartl
Sent: 18 April 2019 11:58
To: Pharo users users <[hidden email]>
Cc: Pharo Dev <[hidden email]>
Subject: Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

Great!

Can you explain what is there, what somebody can load and what to expect. And even more important: what not to expect?

I don’t get any of the essential details from this mail.

Norbert

Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <[hidden email]>:

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced:

We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings!

Why we want a Spec 2.0 with different backends?

There are reasons that converged to decide us to make it:

First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic).
Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons:
Because there is still an important place for desktop applications market and most medium-size to big business still require them.
Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it).

For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come.

Why Gtk3?

There are some other important players in the "native widgets scene", so why we choose Gtk3?

Again, several reasons were taken into account:

Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too.
It is very mature and popular.
It is made in plain C.

Next step: tool migration

The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them:

Old GT tools will be replaced by new Spec tools (while preserving its power).
Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings.

And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :)

A small screenshot of the new Inspector (WIP):

<Screenshot 2019-04-18 at 12.07.16.png>

Esteban

TedVanGaalen

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by Peter Kenny

"Because there is still an important place for desktop applications market
and most medium-size
to big business still require them."
Really? Most things run on browsers these days.

Why would I need a GTK layer?
(btw, GTK is yet another dependency on a 3rd party package)
In my opinion
the most versatile and advanced user application
interface is:
almost any internet browser!

Through all these many years, internet browsers have evolved into
excellent GUIs with endless possibilities for style (css)
formatting, fonts, colors, buttons etc. Extremely flexible. you can even
include
all sorts of plugins, Also you can use image morphs for graphs etc.
What runs in a browser is computer independent, you'd cover many devices
(phones, pads, pc, macs, tv, etc) in one go.
In many cases, you don't even have to manage layout, browser does it for
you.
What more to wish for?

I could ask then, why implement similar GUI stuff, writing tons of
classes that interact with GTK, when internet browsers offer
already a myriad of far more advanced features?
Why re-invent the wheel?

The combination Pharo with Seaside (or equivalent) is very powerful.
Sure, there might be some situations where using a browser as
user interface is not desired or adequate, but currently I can't think of
one.

So Imho best thing to do is:
***Always make any user app as a web app!***
Which of course you can run "stand alone" with Pharo/Seaside as server
e.g. localhost:8080/yourApp

If one day a user would like to use their app via the internet,
then no changes are needed because the app was already
initially made for an internet browser as GUI, so it will run anywhere.

To make apps that way the Pharo IDE as it is now stand alone is a pleasure.
I am currently restarting my app dev with Pharo/Seaside.
The image is a start of the dental app I am making, far from complete, but
I am sure you'll get the general idea.
Regards
Ted
<http://forum.world.st/file/t230630/Screen_Shot_2019-04-19_at_18.png>

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

cedreek

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

>
> "Because there is still an important place for desktop applications market
> and most medium-size
> to big business still require them."
> Really? Most things run on browsers these days.
>
> Why would I need a GTK layer?
> (btw, GTK is yet another dependency on a 3rd party package)
> In my opinion
> the most versatile and advanced user application
> interface is:
> almost any internet browser!

Maybe but desktop apps feel nice to me. Maybe because the web wasn’t designed for apps... I’m ok with them but I want desktop apps these days.

My 2 cents

EstebanLM

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by TedVanGaalen

Hi,

> On 19 Apr 2019, at 19:17, TedVanGaalen <[hidden email]> wrote:
>
> "Because there is still an important place for desktop applications market
> and most medium-size
> to big business still require them."
> Really? Most things run on browsers these days.

I say same: Really?
How many web applications do you use regularly?
Because I see my own desktop, I use a lot of applications and none of them is a desktop application:
- the apps I use to program: desktop.
- the apps I use to communicate: desktop (and yes, there is gmail but I use mail, and there is discord web, but the desktop app is better… and all the others I use).
- the apps I use to write: desktop.
- the apps to play: desktop.
- the apps I use to play: desktop.
If I check… the only web application I use is my home banking app. And that, when I go through my laptop, because if I use my phone I have an app who is a native app (so is assimilable to “desktop”).

You may say “but you are you and that’s not the generality”. Well, maybe, but:

- I check my girlfriend’s computer (she is a sociology professor… nothing to do with software): she uses Ulysses to write (a desktop app), pages and office (desktop, forget about 365 or others). Here other tools: chat, discord, mail. Always desktop.
- I talk with my brother in law (he works at facebook, but in the “control” part): they use a desktop app.
- I go to a restaurant: they use a desktop app.
- I talk with a friend of mine who owns a real state business: desktop apps to manage them.

For area:
- programming tools: web IDEs are at least for now just a toy.
- productivity tools: all in desktop (web versions do not match them)
- graphical tools: desktop.
- games: desktop.
(And I can continue)

Really, people: how many web applications have *for real* replaced the desktop apps?
They have enlarge the possibilities: yes.
They are useful in certain scenarios: yes.
They are preferred for big business: (seems to) yes.

But that is just a small part of that.
All the rest is desktop.
Do not fool yourself.

15 years ago people were already talking about the web-apps revolution.
And we are still talking about.
It may or may not happen, but we are still far from it.

>
> Why would I need a GTK layer?
> (btw, GTK is yet another dependency on a 3rd party package)

Breaking news: if you don’t want it, you don’t use it.
(But even then, you are already relying in 3rd party packages)

>
> In my opinion
> the most versatile and advanced user application
> interface is:
> almost any internet browser!

Already answered. I find that sentence at least an exaggeration (and a misread of reality).

>
> Through all these many years, internet browsers have evolved into
> excellent GUIs with endless possibilities for style (css)
> formatting, fonts, colors, buttons etc. Extremely flexible. you can even
> include
> all sorts of plugins, Also you can use image morphs for graphs etc.
> What runs in a browser is computer independent, you'd cover many devices
> (phones, pads, pc, macs, tv, etc) in one go.
> In many cases, you don't even have to manage layout, browser does it for
> you.
> What more to wish for?
>
> I could ask then, why implement similar GUI stuff, writing tons of
> classes that interact with GTK, when internet browsers offer
> already a myriad of far more advanced features?
> Why re-invent the wheel?

And I could ask you: Why nobody has done it as reliable as a desktop app?
But hey! Nothing forbids us to do a web based spec backend. Is just the decision of someone to implement it.

>
>
> The combination Pharo with Seaside (or equivalent) is very powerful.
> Sure, there might be some situations where using a browser as
> user interface is not desired or adequate, but currently I can't think of
> one.

Matter of opinions. I can’t think on a situation when I would prefer a web app over a desktop app.

>
> So Imho best thing to do is:
> ***Always make any user app as a web app!***
> Which of course you can run "stand alone" with Pharo/Seaside as server
> e.g. localhost:8080/yourApp

The moment you say “always” you are already taking a fanatic decision that reality can prove it wrong.
There is no silver bullet:
- I do not think everything has to be desktop
- Nor I think the solution for everything is web

By implementing the Spec 2 backend what we are doing is putting Pharo in a position of switching backends if we decide it.
By implementing the Gtk3 backend we are empowering the vast majority of Pharo users by giving to them a way to do something they couldn’t before (and yes, there is already people using it to develop their business).
>
> If one day a user would like to use their app via the internet,
> then no changes are needed because the app was already
> initially made for an internet browser as GUI, so it will run anywhere.

Yeah, well.
Until you have a functionality implemented that is not supported in your browser (and then you need to update/change browsers).
And then tell me: who is relying in a 3rd party software?

> To make apps that way the Pharo IDE as it is now stand alone is a pleasure.
> I am currently restarting my app dev with Pharo/Seaside.
> The image is a start of the dental app I am making, far from complete, but
> I am sure you'll get the general idea.

I get it.
I just think you are not taking into account the problem others may have but your own needs here.

- we want YOU to succeed on making a web application (and that means probably seaside+pharo in someway)
- but we also want to give you the best tools to develop… in Pharo. And Pharo is a desktop application and it will continue like that for many time. Then we invest in Spec2: to make the best UI layer we can provide. As aligned with state of the art desktop developments as we can.

Esteban

> Regards
> Ted
> <http://forum.world.st/file/t230630/Screen_Shot_2019-04-19_at_18.png>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

EstebanLM

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

On 19 Apr 2019, at 19:55, Esteban Lorenzano <[hidden email]> wrote:

Hi,

On 19 Apr 2019, at 19:17, TedVanGaalen <[hidden email]> wrote:

"Because there is still an important place for desktop applications market
and most medium-size
to big business still require them."
Really? Most things run on browsers these days.

I say same: Really?
How many web applications do you use regularly?
Because I see my own desktop, I use a lot of applications and none of them is a desktop application:

None of the is a *web* application ;)

- the apps I use to program: desktop.
- the apps I use to communicate: desktop (and yes, there is gmail but I use mail, and there is discord web, but the desktop app is better… and all the others I use).
- the apps I use to write: desktop.
- the apps to play: desktop.
- the apps I use to play: desktop.
If I check… the only web application I use is my home banking app. And that, when I go through my laptop, because if I use my phone I have an app who is a native app (so is assimilable to “desktop”).

You may say “but you are you and that’s not the generality”. Well, maybe, but:

- I check my girlfriend’s computer (she is a sociology professor… nothing to do with software): she uses Ulysses to write (a desktop app), pages and office (desktop, forget about 365 or others). Here other tools: chat, discord, mail. Always desktop.
- I talk with my brother in law (he works at facebook, but in the “control” part): they use a desktop app.
- I go to a restaurant: they use a desktop app.
- I talk with a friend of mine who owns a real state business: desktop apps to manage them.

For area:
- programming tools: web IDEs are at least for now just a toy.
- productivity tools: all in desktop (web versions do not match them)
- graphical tools: desktop.
- games: desktop.
(And I can continue)

Really, people: how many web applications have *for real* replaced the desktop apps?
They have enlarge the possibilities: yes.
They are useful in certain scenarios: yes.
They are preferred for big business: (seems to) yes.

But that is just a small part of that.
All the rest is desktop.
Do not fool yourself.

15 years ago people were already talking about the web-apps revolution.
And we are still talking about.
It may or may not happen, but we are still far from it.

Why would I need a GTK layer?
(btw, GTK is yet another dependency on a 3rd party package)

Breaking news: if you don’t want it, you don’t use it.
(But even then, you are already relying in 3rd party packages)

In my opinion
  the most versatile and advanced user application
  interface is:
  almost any internet browser!

Already answered. I find that sentence at least an exaggeration (and a misread of reality).

Through all these many years, internet browsers have evolved into
excellent GUIs with endless possibilities for style (css)
formatting, fonts, colors, buttons etc. Extremely flexible. you can even
include
all sorts of plugins, Also you can use image morphs for graphs etc.
What runs in a browser is computer independent, you'd cover many devices
(phones, pads, pc, macs, tv, etc) in one go.
In many cases, you don't even have to manage layout, browser does it for
you.
What more to wish for?

I could ask then, why implement similar GUI stuff, writing tons of
classes that interact with GTK, when internet browsers offer
already a myriad of far more advanced features?
Why re-invent the wheel?

And I could ask you: Why nobody has done it as reliable as a desktop app?
But hey! Nothing forbids us to do a web based spec backend. Is just the decision of someone to implement it.

The combination Pharo with Seaside (or equivalent) is very powerful.
Sure, there might be some situations where using a browser as
user interface is not desired or adequate, but currently I can't think of
one.

Matter of opinions. I can’t think on a situation when I would prefer a web app over a desktop app.

So Imho best thing to do is:
***Always make any user app as a web app!***
Which of course you can run "stand alone" with Pharo/Seaside as server
e.g. localhost:8080/yourApp

The moment you say “always” you are already taking a fanatic decision that reality can prove it wrong.
There is no silver bullet:
- I do not think everything has to be desktop
- Nor I think the solution for everything is web

By implementing the Spec 2 backend what we are doing is putting Pharo in a position of switching backends if we decide it.
By implementing the Gtk3 backend we are empowering the vast majority of Pharo users by giving to them a way to do something they couldn’t before (and yes, there is already people using it to develop their business).

If one day a user would like to use their app via the internet,
then no changes are needed because the app was already
initially made for an internet browser as GUI, so it will run anywhere.

Yeah, well.
Until you have a functionality implemented that is not supported in your browser (and then you need to update/change browsers).
And then tell me: who is relying in a 3rd party software?

To make apps that way the Pharo IDE as it is now stand alone is a pleasure.
I am currently restarting my app dev with Pharo/Seaside.
The image is a start of the dental app I am making, far from complete, but
I am sure you'll get the general idea.

I get it.
I just think you are not taking into account the problem others may have but your own needs here.

- we want YOU to succeed on making a web application (and that means probably seaside+pharo in someway)
- but we also want to give you the best tools to develop… in Pharo. And Pharo is a desktop application and it will continue like that for many time. Then we invest in Spec2: to make the best UI layer we can provide. As aligned with state of the art desktop developments as we can.

Esteban

Regards
Ted
<http://forum.world.st/file/t230630/Screen_Shot_2019-04-19_at_18.png>

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Pharo Smalltalk Users mailing list

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by Peter Kenny

Hi Esteban,

This is fantastic! We are eager to investigate how Roassal3 can run in an external window.

Alexandre

> On Apr 18, 2019, at 6:08 AM, Esteban Lorenzano <[hidden email]> wrote:
>
> People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced:
>
> We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings!
>
> Why we want a Spec 2.0 with different backends?
>
> There are reasons that converged to decide us to make it:
>
> • First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic).
> • Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons:
> • Because there is still an important place for desktop applications market and most medium-size to big business still require them.
> • Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it).
>
> For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come.
>
> Why Gtk3?
>
> There are some other important players in the "native widgets scene", so why we choose Gtk3?
>
> Again, several reasons were taken into account:
>
> • Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too.
> • It is very mature and popular.
> • It is made in plain C.
>
> Next step: tool migration
>
> The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them:
>
> • Old GT tools will be replaced by new Spec tools (while preserving its power).
> • Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
> • Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings.
>
> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :)
>
>
> A small screenshot of the new Inspector (WIP):
>
> <Screenshot 2019-04-18 at 12.07.16.png>
>
> Esteban

TedVanGaalen

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by EstebanLM

Hi Esteban
let me write an example: (lots of time at the moment)
--------
Hypothetical CASE 1 Stand Alone Solution:

Currently it's just a pilot/study project, but let's assume for a moment
that after a year so of really hard working on it in Pharo, I finally
completed my dental application system, that is, as as a stand-alone desktop
application...

After splatting a few initial bugs, the dental clinic is happy with my new
dental application, and they paid my bill. Mods were relatively easy to
implement, because it is Smalltalk, not to mention the fantastic debugger
facilities, simply very cool.

They need to run the app simultaneously on 4 computers: that is 4 stand
alone apps running their own separated Smalltalk images. Using a Postgress
server as a DB on one of their PCs tied everything together. Apart from
having to install live Smalltalk images om each computer, backing them up
etc. not much of a problem, one would think, right? So far so good. ...apart
from having to install and maintain the app on each and every computer they
use, that is...

Two weeks later after my app went real: The clinic is expanding and another
3 computers will be added soon, meaning yet even more to install and
maintain. Hey! also a new update of Pharo arrives, I need to update 7 images
import my apps packages in the new images again. ( let alone the many system
updates on especially Windows machines) Test if everything works ok again
etc. Having no down-time is crucial: all done outside of the clinic's
working hours, of course. Great.

Oh, I almost forgot: they will install a iPads and/or Android tablets soon,
which will mounted close near each patient chair. They do that anyway
because analytical imaging apps and a drill controlling app of other firms
run on these tablets. They would be happy if they could run my dental app on
these tablets too, so they don't have walk back and forth to their PCs all
the time.

Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't
run on these tablets! What can I do?
Write special versions of my app for Androids and iPads? Impossible! this
would take me a year or so. Nightmare.

In the end the clinic dumped my app and thus me, and bought another app from
another firm, which runs on all devices because it is a web app. How could I
be so stupid not to make it a web browser app in the first place?
--------
Hypothetical CASE 2: App as Web Browser App:

Took a more modern approach: programmed my app for user access via a web
browser, A web browser is, if you really look at it, in fact nothing more
than a very advanced user terminal with endles GUI possibilities. Which btw
allowed me to style the app esthetically in any way my customer likes. Now
the cool thing is, on many devices, whether PCs, Macs, Android and Apple
tablets and Phones the user GUI presentation and interaction is nearly
identical. Which implies, I have to write my dental app only once, and it
will run on any device that is connected to an intranet or internet. Not
only that, there is just *one* single Pharo Image running instead of many
stand alone apps on an ever changing nr of computers. .When installing a new
Pharo version or update the app, I test it on another Pharo/Seaside server
and can switch seamlessly between the two. The dental clinic is happy
because it runs flawlessly on all devices they have and expanding or
shrinking the number of devices is no problem. Not only that, In case of
problems one can switch in no time to the shadow server app so we have
continuity here.

There is another important advantage as well. The users interacts with the
app in a browser window only, (a thin client) that means they don't have
access to the real application, that is, the delicate Smalltalk image of the
Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a
locked room with an emergency power supply of course, together with its
friend the Database, and the room is only accessible by a responsible
employee(s).

I am happy too, not only because the customer is, but also because I avoided
a nightmare and can do maintenance and updates, say, in 5 % of the time
needed when I had to do maintenance for e.g. 7 stand alone apps running om
separate computers.
---------
So far for my hypothetical examples, just to illustrate.

Note that on the internet, each site that you might visit is of course a web
app of its own. So you probably interact with more web apps than you'd
realize. Note that some are really advanced like e.g. web shops like Amazon.
There are many good websites that function really great, but a lot are
almost depressing. You're absolutely right that a lot of it is inferior, but
you might have noticed also that things are slowly improving.

This bad quality with (still) many web apps/sites is because as you know
these are mostly built with chaotic hybrid systems/tools and unsafe
languages like Javascript, ever changing packages, interfaces, tools etc.

Compared to that, building web apps with Pharo/Seaside is a lot more
straight forward and reliable, because everything is done in the Smalltalk
image.

Note that the web browser is not the limit itself, but rather the web app
using the browser GUI. You can really design and build beautiful and
ergonomically sound web apps, because there are so many possibilities.

However, the main reason for choosing to make apps as web apps is that it is
the only way to get your app and data accessible op nearly all devices.
Build it once and run it everywhere.

You see, this is a typical application developer's perspective, not that far
from reality, I can tell you that.

Kindly asking Tool Developers to learn more about the people and their
environment they build tools for.
because it's not only tech but a lot of things around it too.

In any case Smalltalk/Pharo/Seaside is a great to build apps with.
Unfortunately a lot of people still don't know this.
Kind Regards
Ted

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

cedreek

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

Doing a web only app is a solution but not the best one to me. And there are ways to update a desktop app, especially if pharo based.

Ok for mobile but I think also this deserve specific dev. The holy grail of writing once deploy everywhere is nice but in my limited experience this is more a question of compromise and at the end you get something pretty annoying and inconsistent. If you cannot develop native (or even hybrid) on tablet, then pure web is an option but not a cool one.

Last point is I want now distributed apps that work offline and online. It’s doable with web apps but kind of more difficult to manage. In your hypothetical example, no connection = no app ? Another solution is using a local web server but it doesn’t feel very native again. There are solutions like electron too but still, even if I find them quite nice, I cannot stand the launch time...

So, to me, I’m really happy that SPEC provides now native windows. And as you say there is seaside and all other web stack lib like zinc etc... so best of both world.

My 2 cents,

Cédrick

> Le 19 avr. 2019 à 23:50, TedVanGaalen <[hidden email]> a écrit :
>
> Hi Esteban
> let me write an example: (lots of time at the moment)
> --------
> Hypothetical CASE 1 Stand Alone Solution:
>
> Currently it's just a pilot/study project, but let's assume for a moment
> that after a year so of really hard working on it in Pharo, I finally
> completed my dental application system, that is, as as a stand-alone desktop
> application...
>
> After splatting a few initial bugs, the dental clinic is happy with my new
> dental application, and they paid my bill. Mods were relatively easy to
> implement, because it is Smalltalk, not to mention the fantastic debugger
> facilities, simply very cool.
>
> They need to run the app simultaneously on 4 computers: that is 4 stand
> alone apps running their own separated Smalltalk images. Using a Postgress
> server as a DB on one of their PCs tied everything together. Apart from
> having to install live Smalltalk images om each computer, backing them up
> etc. not much of a problem, one would think, right? So far so good. ...apart
> from having to install and maintain the app on each and every computer they
> use, that is...
>
> Two weeks later after my app went real: The clinic is expanding and another
> 3 computers will be added soon, meaning yet even more to install and
> maintain. Hey! also a new update of Pharo arrives, I need to update 7 images
> import my apps packages in the new images again. ( let alone the many system
> updates on especially Windows machines) Test if everything works ok again
> etc. Having no down-time is crucial: all done outside of the clinic's
> working hours, of course. Great.
>
> Oh, I almost forgot: they will install a iPads and/or Android tablets soon,
> which will mounted close near each patient chair. They do that anyway
> because analytical imaging apps and a drill controlling app of other firms
> run on these tablets. They would be happy if they could run my dental app on
> these tablets too, so they don't have walk back and forth to their PCs all
> the time.
>
> Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't
> run on these tablets! What can I do?
> Write special versions of my app for Androids and iPads? Impossible! this
> would take me a year or so. Nightmare.
>
> In the end the clinic dumped my app and thus me, and bought another app from
> another firm, which runs on all devices because it is a web app. How could I
> be so stupid not to make it a web browser app in the first place?
> --------
> Hypothetical CASE 2: App as Web Browser App:
>
> Took a more modern approach: programmed my app for user access via a web
> browser, A web browser is, if you really look at it, in fact nothing more
> than a very advanced user terminal with endles GUI possibilities. Which btw
> allowed me to style the app esthetically in any way my customer likes. Now
> the cool thing is, on many devices, whether PCs, Macs, Android and Apple
> tablets and Phones the user GUI presentation and interaction is nearly
> identical. Which implies, I have to write my dental app only once, and it
> will run on any device that is connected to an intranet or internet. Not
> only that, there is just *one* single Pharo Image running instead of many
> stand alone apps on an ever changing nr of computers. .When installing a new
> Pharo version or update the app, I test it on another Pharo/Seaside server
> and can switch seamlessly between the two. The dental clinic is happy
> because it runs flawlessly on all devices they have and expanding or
> shrinking the number of devices is no problem. Not only that, In case of
> problems one can switch in no time to the shadow server app so we have
> continuity here.
>
> There is another important advantage as well. The users interacts with the
> app in a browser window only, (a thin client) that means they don't have
> access to the real application, that is, the delicate Smalltalk image of the
> Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a
> locked room with an emergency power supply of course, together with its
> friend the Database, and the room is only accessible by a responsible
> employee(s).
>
> I am happy too, not only because the customer is, but also because I avoided
> a nightmare and can do maintenance and updates, say, in 5 % of the time
> needed when I had to do maintenance for e.g. 7 stand alone apps running om
> separate computers.
> ---------
> So far for my hypothetical examples, just to illustrate.
>
> Note that on the internet, each site that you might visit is of course a web
> app of its own. So you probably interact with more web apps than you'd
> realize. Note that some are really advanced like e.g. web shops like Amazon.
> There are many good websites that function really great, but a lot are
> almost depressing. You're absolutely right that a lot of it is inferior, but
> you might have noticed also that things are slowly improving.
>
> This bad quality with (still) many web apps/sites is because as you know
> these are mostly built with chaotic hybrid systems/tools and unsafe
> languages like Javascript, ever changing packages, interfaces, tools etc.
>
> Compared to that, building web apps with Pharo/Seaside is a lot more
> straight forward and reliable, because everything is done in the Smalltalk
> image.
>
> Note that the web browser is not the limit itself, but rather the web app
> using the browser GUI. You can really design and build beautiful and
> ergonomically sound web apps, because there are so many possibilities.
>
> However, the main reason for choosing to make apps as web apps is that it is
> the only way to get your app and data accessible op nearly all devices.
> Build it once and run it everywhere.
>
> You see, this is a typical application developer's perspective, not that far
> from reality, I can tell you that.
>
> Kindly asking Tool Developers to learn more about the people and their
> environment they build tools for.
> because it's not only tech but a lot of things around it too.
>
> In any case Smalltalk/Pharo/Seaside is a great to build apps with.
> Unfortunately a lot of people still don't know this.
> Kind Regards
> Ted
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Offray Vladimir Luna Cárdenas-2

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by TedVanGaalen

Hi,

[...]

On 19/04/19 4:50 p. m., TedVanGaalen wrote:
> However, the main reason for choosing to make apps as web apps is that it is
> the only way to get your app and data accessible op nearly all devices.
> Build it once and run it everywhere.
>
> You see, this is a typical application developer's perspective, not that far
> from reality, I can tell you that.

[...]

I'm with Esteban on this. Most of the apps I use are not web apps (not
even for mail, where my client is Thunderbird most of the time). My
thesis was wrote in a desktop app (TeXstudio), my outlining program
(Leo), the text editor (text adept), the PDF reader (okular), the
desktop UI (Awesome) and I could go on. The only exception is my
Markdown editor (and of course the web browser), which is Zettlr, which
is an electron app. BTW, Atom and other web based editors running
electron are kind of slow compared with native desktop apps (with the
exception of the pretty focused and light Zettlr).

The only think I like from the web ubiquity is the "universal" good
rendering for fronts and graphics, but as a paradigm for development is
pretty fractured and lacks cohesion. There are some efforts, like
PhosphorJS to have sane web interface. For me is kind of awesome how the
last decades of development are kind of reinventing the desktop in the
web... I would like something like Guacamole[1] for running "Pharo
containers" and native desktop UIs in the web, without investing a lot
of time on rewriting the desktop in the web, but having the possibility
to run a self contained desktop app when connectivity is low, like in
many places of the Global South, where most of the half+ of humanity
without Internet lives, and even those of us who have it, know that net
in only reliable on major cities of the Global South and not in every
place of such cities.

[1] https://guacamole.apache.org/

So the "typical application developer's perspective" depends on the
place where such "typical" person is located. Having a robust native app
looking for Pharo will be a strong selling point for the future for the
humanity that will be connecting to the web in the decades to come (I
just whish a way to embed web components in the GTK native app, but I
think that such combinations will be possible).

Cheers,

Offray

EstebanLM

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by TedVanGaalen

Hi,

First, your examples are biased :)
Still, you do not get the point: the point is that not everything has same requirements. Pharo is a tool to allow users to provide answers in a general cases, not just the two or twenty you can think about.

Also, to counter your “Case”, here what I think:
- “Most” applications nowadays have autoupdate mechanism that works perfectly fine to keep the applications up to date. Pharo in particular is particularly suitable for this kind of behaviour (I implemented this autoupdate mechanisms ten years ago, when autoupdate was still not “a thing”).
- By doing a web application you may “save" the distribution of updates version better, but you are “buying” the cost of maintenance of an hybrid application that will rely… guess what? In third party frameworks! (Starting for JQuery, but a lot others if you want your app to look modern and cool).
- Tablets: yes this is a constraint (still, is just a constraint not present “in general"). But if you think a web application will work out of the box in a tablet you are fooling yourself (thinking on UX here).
- “Prepare 3 new images”: if you are doing this manually today, you are doing something wrong. Also, if you need to install your images from scratch for each new user (instead just copying them), you are also doing something wrong.

Let me put this counter example: Some years ago before I came to work for pharo I made this app called “the lawsuit tracker” to a legal office in Argentina. Since they had two offices in different regions I proposed a web application as a first solution which they rejected because “is uncomfortable”. So I took wha I had in hand there and I made an app that mixed Magritte with Glamour (this was the origin of Voyage framework, btw).
- I added an autoupdate mechanism (they query for packages in a particular ftp location and they install them if new are found),
- local configuration was in an external file.
- I packaged it a “one-click” image with some extensions to verify which libc they where using (they target was to move to linux from windows in some couple of years).

And I "installed it” by sending a mail saying “download this, unpack and click”.

So, each time there was a new version I was producing the same (with a script), and already installed versions were updating automatically.

(Ah, btw I was collecting errors by fuelizing them and saving them in the database, so I was able to dig into errors later).

This was 2011.
By 2012 I came to work for Pharo.

Last time I went to Argentina (last year) I talked with the guy that is responsible of doing the “technical service” of that place (he is a friend of mine): they are still using the same application (and very happy with it).
In the same time they opened two new offices so the user number passed from 18 to 35.
They completed the migration to linux.

Everything is still working:
- Pharo 1.4
- Stack VM
- MongoDB 3 to centralise information over a secure connection.

So… I have a very successful installation of a Pharo desktop application (even in moments were doing this was not easy, I needed to hack a lot to “close” the image).
And not an hypothetical case, a real life case.

Still: I DO NO SAY THIS SHOULD BE THE GENERAL CASE.
I say this has to be possible.
And I also say: there is a lot more use cases out there when this “web” answer just does not applies.
And of course there are other tons of cases were the web application is the right solution.
Why you want to constraint yourself to just one solution?

When you develop an application you have to decide the best architecture possible taking into account the constraints you have, not some ideas of how things should be.

Esteban

> On 19 Apr 2019, at 23:50, TedVanGaalen <[hidden email]> wrote:
>
> Hi Esteban
> let me write an example: (lots of time at the moment)
> --------
> Hypothetical CASE 1 Stand Alone Solution:
>
> Currently it's just a pilot/study project, but let's assume for a moment
> that after a year so of really hard working on it in Pharo, I finally
> completed my dental application system, that is, as as a stand-alone desktop
> application...
>
> After splatting a few initial bugs, the dental clinic is happy with my new
> dental application, and they paid my bill. Mods were relatively easy to
> implement, because it is Smalltalk, not to mention the fantastic debugger
> facilities, simply very cool.
>
> They need to run the app simultaneously on 4 computers: that is 4 stand
> alone apps running their own separated Smalltalk images. Using a Postgress
> server as a DB on one of their PCs tied everything together. Apart from
> having to install live Smalltalk images om each computer, backing them up
> etc. not much of a problem, one would think, right? So far so good. ...apart
> from having to install and maintain the app on each and every computer they
> use, that is...
>
> Two weeks later after my app went real: The clinic is expanding and another
> 3 computers will be added soon, meaning yet even more to install and
> maintain. Hey! also a new update of Pharo arrives, I need to update 7 images
> import my apps packages in the new images again. ( let alone the many system
> updates on especially Windows machines) Test if everything works ok again
> etc. Having no down-time is crucial: all done outside of the clinic's
> working hours, of course. Great.
>
> Oh, I almost forgot: they will install a iPads and/or Android tablets soon,
> which will mounted close near each patient chair. They do that anyway
> because analytical imaging apps and a drill controlling app of other firms
> run on these tablets. They would be happy if they could run my dental app on
> these tablets too, so they don't have walk back and forth to their PCs all
> the time.
>
> Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't
> run on these tablets! What can I do?
> Write special versions of my app for Androids and iPads? Impossible! this
> would take me a year or so. Nightmare.
>
> In the end the clinic dumped my app and thus me, and bought another app from
> another firm, which runs on all devices because it is a web app. How could I
> be so stupid not to make it a web browser app in the first place?
> --------
> Hypothetical CASE 2: App as Web Browser App:
>
> Took a more modern approach: programmed my app for user access via a web
> browser, A web browser is, if you really look at it, in fact nothing more
> than a very advanced user terminal with endles GUI possibilities. Which btw
> allowed me to style the app esthetically in any way my customer likes. Now
> the cool thing is, on many devices, whether PCs, Macs, Android and Apple
> tablets and Phones the user GUI presentation and interaction is nearly
> identical. Which implies, I have to write my dental app only once, and it
> will run on any device that is connected to an intranet or internet. Not
> only that, there is just *one* single Pharo Image running instead of many
> stand alone apps on an ever changing nr of computers. .When installing a new
> Pharo version or update the app, I test it on another Pharo/Seaside server
> and can switch seamlessly between the two. The dental clinic is happy
> because it runs flawlessly on all devices they have and expanding or
> shrinking the number of devices is no problem. Not only that, In case of
> problems one can switch in no time to the shadow server app so we have
> continuity here.
>
> There is another important advantage as well. The users interacts with the
> app in a browser window only, (a thin client) that means they don't have
> access to the real application, that is, the delicate Smalltalk image of the
> Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a
> locked room with an emergency power supply of course, together with its
> friend the Database, and the room is only accessible by a responsible
> employee(s).
>
> I am happy too, not only because the customer is, but also because I avoided
> a nightmare and can do maintenance and updates, say, in 5 % of the time
> needed when I had to do maintenance for e.g. 7 stand alone apps running om
> separate computers.
> ---------
> So far for my hypothetical examples, just to illustrate.
>
> Note that on the internet, each site that you might visit is of course a web
> app of its own. So you probably interact with more web apps than you'd
> realize. Note that some are really advanced like e.g. web shops like Amazon.
> There are many good websites that function really great, but a lot are
> almost depressing. You're absolutely right that a lot of it is inferior, but
> you might have noticed also that things are slowly improving.
>
> This bad quality with (still) many web apps/sites is because as you know
> these are mostly built with chaotic hybrid systems/tools and unsafe
> languages like Javascript, ever changing packages, interfaces, tools etc.
>
> Compared to that, building web apps with Pharo/Seaside is a lot more
> straight forward and reliable, because everything is done in the Smalltalk
> image.
>
> Note that the web browser is not the limit itself, but rather the web app
> using the browser GUI. You can really design and build beautiful and
> ergonomically sound web apps, because there are so many possibilities.
>
> However, the main reason for choosing to make apps as web apps is that it is
> the only way to get your app and data accessible op nearly all devices.
> Build it once and run it everywhere.
>
> You see, this is a typical application developer's perspective, not that far
> from reality, I can tell you that.
>
> Kindly asking Tool Developers to learn more about the people and their
> environment they build tools for.
> because it's not only tech but a lot of things around it too.
>
> In any case Smalltalk/Pharo/Seaside is a great to build apps with.
> Unfortunately a lot of people still don't know this.
> Kind Regards
> Ted
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

NorbertHartl

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

I agree to everything Esteban said. It is about options. And Web is not the answer to everything, quite to contrary. For us Web is a limitation of power, you struggle mostly with backend connectivity (reaching out for your objects) and if you want to do something nice you end up doing it in javascript with a lot of libraries. It is hard to write something nice in a web environment and maintenance is hell.

Norbert

> Am 20.04.2019 um 10:43 schrieb Esteban Lorenzano <[hidden email]>:
>
> Hi,
>
> First, your examples are biased :)
> Still, you do not get the point: the point is that not everything has same requirements. Pharo is a tool to allow users to provide answers in a general cases, not just the two or twenty you can think about.
>
> Also, to counter your “Case”, here what I think:
> - “Most” applications nowadays have autoupdate mechanism that works perfectly fine to keep the applications up to date. Pharo in particular is particularly suitable for this kind of behaviour (I implemented this autoupdate mechanisms ten years ago, when autoupdate was still not “a thing”).
> - By doing a web application you may “save" the distribution of updates version better, but you are “buying” the cost of maintenance of an hybrid application that will rely… guess what? In third party frameworks! (Starting for JQuery, but a lot others if you want your app to look modern and cool).
> - Tablets: yes this is a constraint (still, is just a constraint not present “in general"). But if you think a web application will work out of the box in a tablet you are fooling yourself (thinking on UX here).
> - “Prepare 3 new images”: if you are doing this manually today, you are doing something wrong. Also, if you need to install your images from scratch for each new user (instead just copying them), you are also doing something wrong.
>
> Let me put this counter example: Some years ago before I came to work for pharo I made this app called “the lawsuit tracker” to a legal office in Argentina. Since they had two offices in different regions I proposed a web application as a first solution which they rejected because “is uncomfortable”. So I took wha I had in hand there and I made an app that mixed Magritte with Glamour (this was the origin of Voyage framework, btw).
> - I added an autoupdate mechanism (they query for packages in a particular ftp location and they install them if new are found),
> - local configuration was in an external file.
> - I packaged it a “one-click” image with some extensions to verify which libc they where using (they target was to move to linux from windows in some couple of years).
>
> And I "installed it” by sending a mail saying “download this, unpack and click”.
>
> So, each time there was a new version I was producing the same (with a script), and already installed versions were updating automatically.
>
> (Ah, btw I was collecting errors by fuelizing them and saving them in the database, so I was able to dig into errors later).
>
> This was 2011.
> By 2012 I came to work for Pharo.
>
> Last time I went to Argentina (last year) I talked with the guy that is responsible of doing the “technical service” of that place (he is a friend of mine): they are still using the same application (and very happy with it).
> In the same time they opened two new offices so the user number passed from 18 to 35.
> They completed the migration to linux.
>
> Everything is still working:
> - Pharo 1.4
> - Stack VM
> - MongoDB 3 to centralise information over a secure connection.
>
> So… I have a very successful installation of a Pharo desktop application (even in moments were doing this was not easy, I needed to hack a lot to “close” the image).
> And not an hypothetical case, a real life case.
>
> Still: I DO NO SAY THIS SHOULD BE THE GENERAL CASE.
> I say this has to be possible.
> And I also say: there is a lot more use cases out there when this “web” answer just does not applies.
> And of course there are other tons of cases were the web application is the right solution.
> Why you want to constraint yourself to just one solution?
>
> When you develop an application you have to decide the best architecture possible taking into account the constraints you have, not some ideas of how things should be.
>
> Esteban
>
>> On 19 Apr 2019, at 23:50, TedVanGaalen <[hidden email]> wrote:
>>
>> Hi Esteban
>> let me write an example: (lots of time at the moment)
>> --------
>> Hypothetical CASE 1 Stand Alone Solution:
>>
>> Currently it's just a pilot/study project, but let's assume for a moment
>> that after a year so of really hard working on it in Pharo, I finally
>> completed my dental application system, that is, as as a stand-alone desktop
>> application...
>>
>> After splatting a few initial bugs, the dental clinic is happy with my new
>> dental application, and they paid my bill. Mods were relatively easy to
>> implement, because it is Smalltalk, not to mention the fantastic debugger
>> facilities, simply very cool.
>>
>> They need to run the app simultaneously on 4 computers: that is 4 stand
>> alone apps running their own separated Smalltalk images. Using a Postgress
>> server as a DB on one of their PCs tied everything together. Apart from
>> having to install live Smalltalk images om each computer, backing them up
>> etc. not much of a problem, one would think, right? So far so good. ...apart
>> from having to install and maintain the app on each and every computer they
>> use, that is...
>>
>> Two weeks later after my app went real: The clinic is expanding and another
>> 3 computers will be added soon, meaning yet even more to install and
>> maintain. Hey! also a new update of Pharo arrives, I need to update 7 images
>> import my apps packages in the new images again. ( let alone the many system
>> updates on especially Windows machines) Test if everything works ok again
>> etc. Having no down-time is crucial: all done outside of the clinic's
>> working hours, of course. Great.
>>
>> Oh, I almost forgot: they will install a iPads and/or Android tablets soon,
>> which will mounted close near each patient chair. They do that anyway
>> because analytical imaging apps and a drill controlling app of other firms
>> run on these tablets. They would be happy if they could run my dental app on
>> these tablets too, so they don't have walk back and forth to their PCs all
>> the time.
>>
>> Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't
>> run on these tablets! What can I do?
>> Write special versions of my app for Androids and iPads? Impossible! this
>> would take me a year or so. Nightmare.
>>
>> In the end the clinic dumped my app and thus me, and bought another app from
>> another firm, which runs on all devices because it is a web app. How could I
>> be so stupid not to make it a web browser app in the first place?
>> --------
>> Hypothetical CASE 2: App as Web Browser App:
>>
>> Took a more modern approach: programmed my app for user access via a web
>> browser, A web browser is, if you really look at it, in fact nothing more
>> than a very advanced user terminal with endles GUI possibilities. Which btw
>> allowed me to style the app esthetically in any way my customer likes. Now
>> the cool thing is, on many devices, whether PCs, Macs, Android and Apple
>> tablets and Phones the user GUI presentation and interaction is nearly
>> identical. Which implies, I have to write my dental app only once, and it
>> will run on any device that is connected to an intranet or internet. Not
>> only that, there is just *one* single Pharo Image running instead of many
>> stand alone apps on an ever changing nr of computers. .When installing a new
>> Pharo version or update the app, I test it on another Pharo/Seaside server
>> and can switch seamlessly between the two. The dental clinic is happy
>> because it runs flawlessly on all devices they have and expanding or
>> shrinking the number of devices is no problem. Not only that, In case of
>> problems one can switch in no time to the shadow server app so we have
>> continuity here.
>>
>> There is another important advantage as well. The users interacts with the
>> app in a browser window only, (a thin client) that means they don't have
>> access to the real application, that is, the delicate Smalltalk image of the
>> Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a
>> locked room with an emergency power supply of course, together with its
>> friend the Database, and the room is only accessible by a responsible
>> employee(s).
>>
>> I am happy too, not only because the customer is, but also because I avoided
>> a nightmare and can do maintenance and updates, say, in 5 % of the time
>> needed when I had to do maintenance for e.g. 7 stand alone apps running om
>> separate computers.
>> ---------
>> So far for my hypothetical examples, just to illustrate.
>>
>> Note that on the internet, each site that you might visit is of course a web
>> app of its own. So you probably interact with more web apps than you'd
>> realize. Note that some are really advanced like e.g. web shops like Amazon.
>> There are many good websites that function really great, but a lot are
>> almost depressing. You're absolutely right that a lot of it is inferior, but
>> you might have noticed also that things are slowly improving.
>>
>> This bad quality with (still) many web apps/sites is because as you know
>> these are mostly built with chaotic hybrid systems/tools and unsafe
>> languages like Javascript, ever changing packages, interfaces, tools etc.
>>
>> Compared to that, building web apps with Pharo/Seaside is a lot more
>> straight forward and reliable, because everything is done in the Smalltalk
>> image.
>>
>> Note that the web browser is not the limit itself, but rather the web app
>> using the browser GUI. You can really design and build beautiful and
>> ergonomically sound web apps, because there are so many possibilities.
>>
>> However, the main reason for choosing to make apps as web apps is that it is
>> the only way to get your app and data accessible op nearly all devices.
>> Build it once and run it everywhere.
>>
>> You see, this is a typical application developer's perspective, not that far
>> from reality, I can tell you that.
>>
>> Kindly asking Tool Developers to learn more about the people and their
>> environment they build tools for.
>> because it's not only tech but a lot of things around it too.
>>
>> In any case Smalltalk/Pharo/Seaside is a great to build apps with.
>> Unfortunately a lot of people still don't know this.
>> Kind Regards
>> Ted
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>
>

TedVanGaalen

Re: [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

In reply to this post by EstebanLM

@Esteban:
Of course you are right that there are cases a standalone app would be more
convenient e.g. as you mentioned: graphical (image processing) apps, digital
audio workstations, like Cubase. In most cases these are the kind of apps
that deal with personal (local) data, which mostly is not connected to a
central data storage on a hosting system.
In other cases that is for users having real time access to data stored on a
central point, web apps are preferable. Like the banking app, Internet
shops.

Also on a smaller scale as browser intranet apps e.g. small independent
firms, clinics Law firms, accountancies and so on. Of course these should
have web apps running in the firm's intranet only. These used to be client
server apps, mostly with thin clients or ven just terminals (VT100) for
example running on a mini computer e.g. DEC PDP 11/xx. Even today,
mainframe applications all run on the host. Access is by terminal only.
This is the most secure environment you can get. I initially grew up with
mainframe application programming btw.
So to me, it seems logical that -at least in a business environment- a
single application (or a group of those) running on a central system
(server) is preferable.

There are many blogs and articles on the web that describe the pro and
contra of web apps versus standalone apps. For example this blog:

http://www.paulgraham.com/road.html

(It's a bit of a long read, but I do recommend it)
Paul Graham describes this theme much better than I ever can do. Note that
this blog is written 18 years ago and he had to work with the technical
limitations of 2000 and before. Today web technology is far more advanced,
enabling us to make really professional web apps. Most limitations are gone.

Seen in this perspective, Pharo (or some other Smalltalk versions) combined
with Seaside are excellent tools to create versatile web apps in a
relatively short amount of time. I think the limitations of designing and
building professional web apps are perhaps much less than one might think.
Like with many other challenges, one gets better by actually doing it.

Some other points I'd like to react on:

Dependency on 3rd party tools in combination with Pharo/Seaside?
As far as I know now, in Seaside itself that would be only Javascript and
jQuery? It is unlikely that these will disappear because the whole web world
depends on these two. In Pharo image itself that would in most cases be at
least a database like Postgress.

If the need arises for special GUI web elements, these could be made
relatively easy in Smalltalk. And of course it all relies heavily on CSS
which is very advanced, but that's a good thing! A good book about CSS is
helpful.

Yet another reason for me to make -even stand alone- apps with Pharo as
Seaside web apps is, that (at least for me) it is much harder to make a
native GUI app within Pharo. Using the browser as GUI is much easier.
Honestly, I doubt if this would be better if GTK is deployed as GUI? Also
one would be bound to the GTK style/appearance and some themes they might
provide. No such limitations exist using Seaside with good CSS styling. Also
GTK does not work on mobile devices. So for me GTK or any other native GUI
are out because of that.

On a Mac (similar on Windows btw) GTK needs an extra layer. It uses the
Quartz backend. GTK is not feature complete, riddled with bugs e.g. Wacom
tablets with GIMP), new releases are not compatible etc. See for yourself.
Don't stick your heads in a wasp nest. I don't understand why one would have
to, because Pharo has excellent GUI elements. You could subclass Morph
classes.? (I am not aware of most further GUI enhancements in Pharo, because
I still cannot run Pharo 7 on my mac mini due to a VM problem since 2017,
same with Squeak btw. (see other thread) still using pre-Spur Pharo 5)
Imho, by coupling GTK to Pharo one creates an unstable big dependency
situation. This stands opposite on having Smalltalk as autonomously and
independent as possible.

Errm, note btw that if you change addressing me as "fanatic" into "racing a
bit too fast" i can accept this :o)

(By "fanatic" I think of much worse things happening on our planet all the
time. So sad)

The "always as web app, whenever possible" is something I strive for, not
that the whole world must do this.

Thanks
TedvG

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html