Smalltalk › Pharo › Pharo Smalltalk Developers

About Pharo 60

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

stepharo

About Pharo 60

Hi

We have some ideas (because people are working on items) for the Pharo 6
roadmap

and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

- what are the points you are working on and that would deserve
more focus and help from the community?

(these points are important because like that you could go
faster and this is a good feeling to get done for example)

- what would be points where (if magically we would get more
resources - to not dream if this is not you

there is a high chance that we will not make it) it would be
nice to get some changes

Please pay attention that if you type too fast and come up with a
christmas list well it will stay a christmas list and will just make the
thread larger for nothing.

Stef

Peter Uhnak

Re: About Pharo 60

I cannot find the list, but there were some things we discussed during consortium call a month or so ago. Maybe Esteban can find it?

I want for Christmas

* Better Spec

* Roadmap so we know where we are going,

* with clean API,

* so we can build really live UIs (where you can drag windows around, close them, dock them, etc.

* so we are ready for Bloc (can be for Easter too :))

* Stability

* I crash daily

Obviously I can and I try to help with Spec, but I do not have the time or resources to lead it, and since we don't have any roadmap it's hard to go forward.

Peter

On Wed, Aug 24, 2016 at 6:59 AM, stepharo <[hidden email]> wrote:

Hi

We have some ideas (because people are working on items) for the Pharo 6 roadmap

and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

- what are the points you are working on and that would deserve more focus and help from the community?

(these points are important because like that you could go faster and this is a good feeling to get done for example)

- what would be points where (if magically we would get more resources - to not dream if this is not you

there is a high chance that we will not make it) it would be nice to get some changes

Please pay attention that if you type too fast and come up with a christmas list well it will stay a christmas list and will just make the thread larger for nothing.

Stef

stepharo

Re: About Pharo 60

Thanks Peter

I cannot find the list, but there were some things we discussed during consortium call a month or so ago. Maybe Esteban can find it?

I want for Christmas

* Better Spec

* Roadmap so we know where we are going,

* with clean API,

* so we can build really live UIs (where you can drag windows around, close them, dock them, etc.

* so we are ready for Bloc (can be for Easter too :))

* Stability

* I crash daily

Obviously I can and I try to help with Spec, but I do not have the time or resources to lead it, and since we don't have any roadmap it's hard to go forward.

    I should say that I'm a bit stuck to understand where to start and what we want to achieve.
    The firs things I would do
        - Reading all the code to get a feel.
        - I would like to rename the class consistently a Model should be named Presenter and the Model whose name do not contain Model should still be renamed to contain Presenter.

    I need to review the changes made by marion and that have been published.

Stef

philippeback

Re: About Pharo 60

List:

* image size management under control

* no more gradients in that UI (even in the light theme)

* modern "Material style" UI

* FASTER Nautilus

* better console support (in/out)

* Pharo VM as something I can embed in other programs

* something like npm.js for the packages list along with external package manager to build my images

* integration with Hadoop ecosystem

* super easy to write REST clients and servers (including Swagger support)

Phil

On Fri, Aug 26, 2016 at 10:15 AM, stepharo <[hidden email]> wrote:

Thanks Peter

I cannot find the list, but there were some things we discussed during consortium call a month or so ago. Maybe Esteban can find it?

I want for Christmas

* Better Spec

* Roadmap so we know where we are going,

* with clean API,

* so we can build really live UIs (where you can drag windows around, close them, dock them, etc.

* so we are ready for Bloc (can be for Easter too :))

* Stability

* I crash daily

Obviously I can and I try to help with Spec, but I do not have the time or resources to lead it, and since we don't have any roadmap it's hard to go forward.

    I should say that I'm a bit stuck to understand where to start and what we want to achieve.
    The firs things I would do
        - Reading all the code to get a feel.
        - I would like to rename the class consistently a Model should be named Presenter and the Model whose name do not contain Model should still be renamed to contain Presenter.

    I need to review the changes made by marion and that have been published.

Stef

NorbertHartl

Re: About Pharo 60

In reply to this post by stepharo

Hi,

the things I want to have are 64bit, bootstrap and vector graphic backend because these are so disruptive that it takes some time to stabilize the whole system. But there is a roadmap for this which is ok for me.

For me we really need to focus on stabilizing a few things which are (to me) very annoying:

- cannot escape execution with cmd-. sometimes.

- endless loop in Context with DNU for sending the same message again (https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop)

- spotter opening is too slow. You open spotter and when you type too early it shows nothing and you need to close it

- unifying keyboard shortcuts

- tiny and misplaced buttons in GTDebugger

- tree view in GTInspector. It is absolutely terrible that if you try to uncollapse a tree node on the right pane and you did not hit exactly the pane moves to the left. That is sooo…..!!!!!"!§$"%§%§%

- Nautilus method caching. You can have code views that get not updated when the method changes and not even sometimes when you close and reopen the browser.

- good integration of epicea. The old changes mechanism was just broken so I'm glad epicea is in place now

The other big thing for me is that we need to do project dependencies right. I think the bootstrap guys know. The way we reference metacello projects from other projects quickly produces a situation that you load the maximum set in your image. We should have guidelines how to do configurations or any other mechanism so that not only the bootstrap can load cleanly but business project images as well. Let's call it dependency management

my christmas list would be:

- runtime adaptable behaviour. Be it runtime traits, talents, etc…

- environments to separate graphs for certain dimensions like code version, etc.

- magritte replacement with slots

Norbert

Am 24.08.2016 um 06:59 schrieb stepharo <[hidden email]>:

Hi

We have some ideas (because people are working on items) for the Pharo 6 roadmap

and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

   - what are the points you are working on and that would deserve more focus and help from the community?

       (these points are important because like that you could go faster and this is a good feeling to get done for example)

   - what would be points where (if magically we would get more resources - to not dream if this is not you

       there is a high chance that we will not make it) it would be nice to get some changes

Please pay attention that if you type too fast and come up with a christmas list well it will stay a christmas list and will just make the thread larger for nothing.

Stef

stepharo

Re: About Pharo 60

In reply to this post by philippeback

List:

* image size management under control

Yes it requires to write a new GC so I hope that the VM team with get the ressources.

* no more gradients in that UI (even in the light theme)

* modern "Material style" UI

* FASTER Nautilus

what is the problem?

* better console support (in/out)

stdout and friends do not work?

* Pharo VM as something I can embed in other programs

* something like npm.js for the packages list along with external package manager to build my images

We will have that with Cargo

* integration with Hadoop ecosystem

* super easy to write REST clients and servers (including Swagger support)

I think that this is not the roadmap for Pharo 60 but for the community.

Phil

On Fri, Aug 26, 2016 at 10:15 AM, stepharo <[hidden email]> wrote:

Thanks Peter

I cannot find the list, but there were some things we discussed during consortium call a month or so ago. Maybe Esteban can find it?

I want for Christmas

* Better Spec

* Roadmap so we know where we are going,

* with clean API,

* so we can build really live UIs (where you can drag windows around, close them, dock them, etc.

* so we are ready for Bloc (can be for Easter too :))

* Stability

* I crash daily

Obviously I can and I try to help with Spec, but I do not have the time or resources to lead it, and since we don't have any roadmap it's hard to go forward.

    I should say that I'm a bit stuck to understand where to start and what we want to achieve.
    The firs things I would do
        - Reading all the code to get a feel.
        - I would like to rename the class consistently a Model should be named Presenter and the Model whose name do not contain Model should still be renamed to contain Presenter.

    I need to review the changes made by marion and that have been published.

Stef

stepharo

Re: About Pharo 60

In reply to this post by NorbertHartl

Le 26/8/16 à 14:40, Norbert Hartl a écrit :

Hi,

the things I want to have are 64bit, bootstrap and vector graphic backend because these are so disruptive that it takes some time to stabilize the whole system. But there is a roadmap for this which is ok for me.

For me we really need to focus on stabilizing a few things which are (to me) very annoying:

- cannot escape execution with cmd-. sometimes.

Yes we should check that with denis

- endless loop in Context with DNU for sending the same message again (https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop)

- spotter opening is too slow. You open spotter and when you type too early it shows nothing and you need to close it

- unifying keyboard shortcuts

- tiny and misplaced buttons in GTDebugger

:) I fully agree on this one.

- tree view in GTInspector. It is absolutely terrible that if you try to uncollapse a tree node on the right pane and you did not hit exactly the pane moves to the left. That is sooo…..!!!!!"!§$"%§%§%

- Nautilus method caching. You can have code views that get not updated when the method changes and not even sometimes when you close and reopen the browser.

Do you have a scenario? I would like to see what I can do. I would like to do another pass.

- good integration of epicea. The old changes mechanism was just broken so I'm glad epicea is in place now

The other big thing for me is that we need to do project dependencies right. I think the bootstrap guys know.

at least we will fix the ones in the image :)

The way we reference metacello projects from other projects quickly produces a situation that you load the maximum set in your image. We should have guidelines how to do configurations or any other mechanism so that not only the bootstrap can load cleanly but business project images as well. Let's call it dependency management

I think that the dependencies should be computed for us from a tool like the dependency browser and proposed
to us.

my christmas list would be:

- runtime adaptable behaviour. Be it runtime traits, talents, etc…

- environments to separate graphs for certain dimensions like code version, etc.

- magritte replacement with slots

These ones are more researchy but I was recently rereading talents.
Do you have a scenario for talents?

Norbert

Am 24.08.2016 um 06:59 schrieb stepharo <[hidden email]>:

Hi

We have some ideas (because people are working on items) for the Pharo 6 roadmap

and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

   - what are the points you are working on and that would deserve more focus and help from the community?

       (these points are important because like that you could go faster and this is a good feeling to get done for example)

   - what would be points where (if magically we would get more resources - to not dream if this is not you

       there is a high chance that we will not make it) it would be nice to get some changes

Please pay attention that if you type too fast and come up with a christmas list well it will stay a christmas list and will just make the thread larger for nothing.

Stef

kilon.alios

Re: About Pharo 60

In reply to this post by stepharo

My Christmas list is divided to 2 sections a) What I want from you b) What I am going to deliver

What I want from you
------------------------------------

The things I want from Pharo are centered on the high priorities

a) 64 bit version

b) Bloc /SDL

c) FFI documentation / stabilization

Its fine if you deliver after christmas or even a year later, I am in no hurry.

What I am going to deliver ( Unreal 4 for Pharo)
------------------------------------

Because previously I wanted to target the iOS and Android markets for my games, I could not included Pharo in my plans because both iOS and Android demands a single executable and no DLLs .

However I discovered that as a market Steam alone is as large , so I will be targeting Steam instead since my games are more suited for PC (strategy / adventure / rpg) anyway. Windows and Macos will be my focus.

This means I can now use Pharo with Unreal (One also big reason to choose Steam and drop iOS and Android) , which further means that around Christmas Ephestos v1 most likely will be released which will allow for Pharo to be used as a scripting engine for Unreal for people who want to create games or other kind of interactive graphics / multimedia.

But I make no promises because I am still learning Unreal , however because already my socket bridge worked well for using python libraries from Pharo, I will do something similar for Unreal too.

In long term I am considering also a Pharo to C++ transpiler but that is a low priority for now.

Essentially Ephestos will be the basis upon which I will be building my commercial games so its a very long term project.

Disclaimer: Knowledge of Unreal will be required

On Wed, Aug 24, 2016 at 8:00 AM stepharo <[hidden email]> wrote:

Hi

We have some ideas (because people are working on items) for the Pharo 6
roadmap

and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

- what are the points you are working on and that would deserve
more focus and help from the community?

(these points are important because like that you could go
faster and this is a good feeling to get done for example)

- what would be points where (if magically we would get more
resources - to not dream if this is not you

there is a high chance that we will not make it) it would be
nice to get some changes

Please pay attention that if you type too fast and come up with a
christmas list well it will stay a christmas list and will just make the
thread larger for nothing.

Stef

CyrilFerlicot

Re: About Pharo 60

In reply to this post by stepharo

Le 24/08/2016 à 06:59, stepharo a écrit :

> Hi
>
> We have some ideas (because people are working on items) for the Pharo 6
> roadmap
>
> and we will consolidate them soon and propose them to you.
>
> but I would like to know two kinds of points
>
> - what are the points you are working on and that would deserve more
> focus and help from the community?
>
> (these points are important because like that you could go
> faster and this is a good feeling to get done for example)
>
> - what would be points where (if magically we would get more
> resources - to not dream if this is not you
>
> there is a high chance that we will not make it) it would be
> nice to get some changes
>
>
> Please pay attention that if you type too fast and come up with a
> christmas list well it will stay a christmas list and will just make the
> thread larger for nothing.
>
> Stef
>
>

Hi!

There is one thing I would like, but maybe not for Pharo6 since there is
a lot to do, but I would like people to have this in mind: A way to
deploy commercials apps.

I would like to be able to say something like "Smalltalk
lockForDeployment" and "Smalltalk prepareForDeployment" for example.

The first one could just lock the access to the image and let a way to
get them back if you have a password. The second could unload everything
that you don't want for production if you don't plan to debug the image
if there is a problem.

At Synectique when we had a desktop application it was really hard to
lock everything :(
- Disable Halo
- Disable Spotter
- Disable the shortcuts to open a playground, a Nautilus, anything else
that the application
- Remove the private repositories and credentials just in case the
client find a way to get through and get a Monticello
- …

We should not have to do all that. Else Pharo will only be used to build
commencial web applications where the image is on the company's server
and not on the client's server. :(

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

stepharo

Re: About Pharo 60

>
> Hi!
>
> There is one thing I would like, but maybe not for Pharo6 since there is
> a lot to do, but I would like people to have this in mind: A way to
> deploy commercials apps.

YES!!!

>
> I would like to be able to say something like "Smalltalk
> lockForDeployment" and "Smalltalk prepareForDeployment" for example.
>
> The first one could just lock the access to the image and let a way to
> get them back if you have a password. The second could unload everything
> that you don't want for production if you don't plan to debug the image
> if there is a problem.
Do you know how Settings works?
We can adapt it this way.
I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system
should be
defined in way that it can be set just as a setting.
We should not have

World ....
User current = ifTrue

But

World use: userSetting

and World should handle it.

> At Synectique when we had a desktop application it was really hard to
> lock everything :(
> - Disable Halo
> - Disable Spotter
> - Disable the shortcuts to open a playground, a Nautilus, anything else
> that the application
> - Remove the private repositories and credentials just in case the
> client find a way to get through and get a Monticello
> - …
>
> We should not have to do all that. Else Pharo will only be used to build
> commencial web applications where the image is on the company's server
> and not on the client's server. :(

There is way more to do :)
When you deploy on linux you should be able to say beSilent to the
system (do not write on places that you cannot).
Valentin works on it and we should continue

Stef

CyrilFerlicot

Re: About Pharo 60

Le 27/08/2016 à 13:18, stepharo a écrit :
>
>
> YES!!!
>
> Do you know how Settings works?
> We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

> I mean the User approach that Benjmain proposed and was pushed in Pharo
> was not good because it was not modular. Now each part of the system
> should be
> defined in way that it can be set just as a setting.
> We should not have
>
> World ....
> User current = ifTrue
>
> But
>
> World use: userSetting
>
> and World should handle it.
> There is way more to do :)
> When you deploy on linux you should be able to say beSilent to the
> system (do not write on places that you cannot).
> Valentin works on it and we should continue
>
> Stef
>

The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

EstebanLM

Re: About Pharo 60

yes, some years ago I made a package for this.
later Ben tried something similar with the user manager.
none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that.

of course is still possible :)

anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do “headless” it just laugh at you, but is doable in the not-so-long term.

Esteban

> On 27 Aug 2016, at 13:39, Cyril Ferlicot D. <[hidden email]> wrote:
>
> Le 27/08/2016 à 13:18, stepharo a écrit :
>>
>>
>> YES!!!
>>
>> Do you know how Settings works?
>> We can adapt it this way.
>
> When I improved the deployment of Synectique Tools I asked to get a
> simple way to disable Spotter via a setting but I got as answer "No
> because you can do it by removing a global shortcut so it is not needed.".
>
> People in companies don't have the time to learn how shortcuts work and
> how to remove one without impacting something else. And they don't have
> the time to check Spotter code to know how it is call.
>
> If the image is able to have a deployment mode then I don't care how
> Spotter is disabled (setting or removing a shortcut). But for now we
> don't have it. :)
>
>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>> was not good because it was not modular. Now each part of the system
>> should be
>> defined in way that it can be set just as a setting.
>> We should not have
>>
>> World ....
>> User current = ifTrue
>>
>> But
>>
>> World use: userSetting
>>
>> and World should handle it.
>> There is way more to do :)
>> When you deploy on linux you should be able to say beSilent to the
>> system (do not write on places that you cannot).
>> Valentin works on it and we should continue
>>
>> Stef
>>
>
> The fact that there is much more to do is the main reason for Pharo to
> do it and not the developer. The developer cannot know all the system
> and will not be able to protect the code of his company well because he
> will forget something as to disable ctrl+o+p (or he is a god developer!
> But everyone is not).
>
> This is a large thing to do, so it would be cool that everyone keep that
> in mind to allow it little by little (as with the work of Valentin).
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>

stepharo

Re: About Pharo 60

In reply to this post by CyrilFerlicot

Cyril what would be good is to share what you are disabling and to tunr
such points into points that can be turned
but inside Pharo like that you push the logic to the system.

Now this is important to see that if people for which the value is high
do not work on something
why others would do it.
>> YES!!!
>>
>> Do you know how Settings works?
>> We can adapt it this way.
> When I improved the deployment of Synectique Tools I asked to get a
> simple way to disable Spotter via a setting but I got as answer "No
> because you can do it by removing a global shortcut so it is not needed.".

I do not know how to do it either. So we should document that.
> People in companies don't have the time to learn how shortcuts work and
> how to remove one without impacting something else. And they don't have
> the time to check Spotter code to know how it is call.
>
> If the image is able to have a deployment mode then I don't care how
> Spotter is disabled (setting or removing a shortcut). But for now we
> don't have it. :)
No you should care because one day you will come with a new requirement :)
I understand what you mean but the point is that Pharo is our common
architecture
so we should just all pay attention and we cannot ask people to do
everything because
we all have 24 h a day. So we should be smart, share and build together.

>
>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>> was not good because it was not modular. Now each part of the system
>> should be
>> defined in way that it can be set just as a setting.
>> We should not have
>>
>> World ....
>> User current = ifTrue
>>
>> But
>>
>> World use: userSetting
>>
>> and World should handle it.
>> There is way more to do :)
>> When you deploy on linux you should be able to say beSilent to the
>> system (do not write on places that you cannot).
>> Valentin works on it and we should continue
>>
>> Stef
>>
> The fact that there is much more to do is the main reason for Pharo to
> do it and not the developer. The developer cannot know all the system
> and will not be able to protect the code of his company well because he
> will forget something as to disable ctrl+o+p (or he is a god developer!
> But everyone is not).
>
> This is a large thing to do, so it would be cool that everyone keep that
> in mind to allow it little by little (as with the work of Valentin).
>

stepharo

Re: About Pharo 60

In reply to this post by EstebanLM

Hi esteban

I think that we should identify the main hook points and slowly prepare
them.

The system should be prepared for that so that we just need to pass a
context to configure it.

Stef

Le 27/8/16 à 14:32, Esteban Lorenzano a écrit :

> yes, some years ago I made a package for this.
> later Ben tried something similar with the user manager.
> none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that.
>
> of course is still possible :)
>
> anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do “headless” it just laugh at you, but is doable in the not-so-long term.
>
> Esteban
>
>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D. <[hidden email]> wrote:
>>
>> Le 27/08/2016 à 13:18, stepharo a écrit :
>>>
>>> YES!!!
>>>
>>> Do you know how Settings works?
>>> We can adapt it this way.
>> When I improved the deployment of Synectique Tools I asked to get a
>> simple way to disable Spotter via a setting but I got as answer "No
>> because you can do it by removing a global shortcut so it is not needed.".
>>
>> People in companies don't have the time to learn how shortcuts work and
>> how to remove one without impacting something else. And they don't have
>> the time to check Spotter code to know how it is call.
>>
>> If the image is able to have a deployment mode then I don't care how
>> Spotter is disabled (setting or removing a shortcut). But for now we
>> don't have it. :)
>>
>>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>>> was not good because it was not modular. Now each part of the system
>>> should be
>>> defined in way that it can be set just as a setting.
>>> We should not have
>>>
>>> World ....
>>> User current = ifTrue
>>>
>>> But
>>>
>>> World use: userSetting
>>>
>>> and World should handle it.
>>> There is way more to do :)
>>> When you deploy on linux you should be able to say beSilent to the
>>> system (do not write on places that you cannot).
>>> Valentin works on it and we should continue
>>>
>>> Stef
>>>
>> The fact that there is much more to do is the main reason for Pharo to
>> do it and not the developer. The developer cannot know all the system
>> and will not be able to protect the code of his company well because he
>> will forget something as to disable ctrl+o+p (or he is a god developer!
>> But everyone is not).
>>
>> This is a large thing to do, so it would be cool that everyone keep that
>> in mind to allow it little by little (as with the work of Valentin).
>>
>> --
>> Cyril Ferlicot
>>
>> http://www.synectique.eu
>>
>> 165 Avenue Bretagne
>> Lille 59000 France
>>
>
>

EstebanLM

Re: About Pharo 60

> On 27 Aug 2016, at 14:40, stepharo <[hidden email]> wrote:
>
> Hi esteban
>
> I think that we should identify the main hook points and slowly prepare them.
>
> The system should be prepared for that so that we just need to pass a context to configure it.

.. I should have that old package somewhere… it will not work, and it was not very subtle… but it has to be somewhere :)

Esteban

>
> Stef
>
>
> Le 27/8/16 à 14:32, Esteban Lorenzano a écrit :
>> yes, some years ago I made a package for this.
>> later Ben tried something similar with the user manager.
>> none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that.
>>
>> of course is still possible :)
>>
>> anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do “headless” it just laugh at you, but is doable in the not-so-long term.
>>
>> Esteban
>>
>>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D. <[hidden email]> wrote:
>>>
>>> Le 27/08/2016 à 13:18, stepharo a écrit :
>>>>
>>>> YES!!!
>>>>
>>>> Do you know how Settings works?
>>>> We can adapt it this way.
>>> When I improved the deployment of Synectique Tools I asked to get a
>>> simple way to disable Spotter via a setting but I got as answer "No
>>> because you can do it by removing a global shortcut so it is not needed.".
>>>
>>> People in companies don't have the time to learn how shortcuts work and
>>> how to remove one without impacting something else. And they don't have
>>> the time to check Spotter code to know how it is call.
>>>
>>> If the image is able to have a deployment mode then I don't care how
>>> Spotter is disabled (setting or removing a shortcut). But for now we
>>> don't have it. :)
>>>
>>>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>>>> was not good because it was not modular. Now each part of the system
>>>> should be
>>>> defined in way that it can be set just as a setting.
>>>> We should not have
>>>>
>>>> World ....
>>>> User current = ifTrue
>>>>
>>>> But
>>>>
>>>> World use: userSetting
>>>>
>>>> and World should handle it.
>>>> There is way more to do :)
>>>> When you deploy on linux you should be able to say beSilent to the
>>>> system (do not write on places that you cannot).
>>>> Valentin works on it and we should continue
>>>>
>>>> Stef
>>>>
>>> The fact that there is much more to do is the main reason for Pharo to
>>> do it and not the developer. The developer cannot know all the system
>>> and will not be able to protect the code of his company well because he
>>> will forget something as to disable ctrl+o+p (or he is a god developer!
>>> But everyone is not).
>>>
>>> This is a large thing to do, so it would be cool that everyone keep that
>>> in mind to allow it little by little (as with the work of Valentin).
>>>
>>> --
>>> Cyril Ferlicot
>>>
>>> http://www.synectique.eu
>>>
>>> 165 Avenue Bretagne
>>> Lille 59000 France
>>>
>>
>>
>
>

CyrilFerlicot

Re: About Pharo 60

In reply to this post by stepharo

Le 27/08/2016 à 14:39, stepharo a écrit :
> Cyril what would be good is to share what you are disabling and to tunr
> such points into points that can be turned
> but inside Pharo like that you push the logic to the system.
>

Since we moved to a Seaside application not so long after I joined
Synectique we only disable some basic things.

If I don't say anything wrong here is what we did:
- Remove repositories containing "Synectique" in the name
- Reset all passwords (MCHttpRepository clearPasswords)
- Install a custom world menu (WorldState desktopMenuPragmaKeyword: 'XXX')
- Remove Halos (At the time I created an issue to be able to do `Morph
halosEnabled: false`, but it would be useful to make that a setting)
- Remove Spotter ((KMRepository default globalCategories detect: [ :each
| each isKindOf: GTSpotterGlobalShortcut ]) allEntries keymaps do:
#disable)
- Usman also added a transparent Morph that could catch some shortcuts I
think and that would block some actions. We could disabled it with a
dialog and a password.

> Now this is important to see that if people for which the value is high
> do not work on something
> why others would do it.

>> When I improved the deployment of Synectique Tools I asked to get a
>> simple way to disable Spotter via a setting but I got as answer "No
>> because you can do it by removing a global shortcut so it is not
>> needed.".
>
> I do not know how to do it either. So we should document that.

What I did:

(KMRepository default globalCategories detect: [ :each | each isKindOf:
GTSpotterGlobalShortcut ]) allEntries keymaps do: #disable

Ugly I know but it worked and was only called once in the CI.

>> People in companies don't have the time to learn how shortcuts work and
>> how to remove one without impacting something else. And they don't have
>> the time to check Spotter code to know how it is call.
>>
>> If the image is able to have a deployment mode then I don't care how
>> Spotter is disabled (setting or removing a shortcut). But for now we
>> don't have it. :)
> No you should care because one day you will come with a new requirement :)
> I understand what you mean but the point is that Pharo is our common
> architecture
> so we should just all pay attention and we cannot ask people to do
> everything because
> we all have 24 h a day. So we should be smart, share and build together.
>

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

CyrilFerlicot

Re: About Pharo 60

In reply to this post by EstebanLM

Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit :
> yes, some years ago I made a package for this.
> later Ben tried something similar with the user manager.
> none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that.
>

I checked the issue tracker and it was closed because people though that
we need a better way to disable shortcuts in general and that it is not
specific to Spotter.

https://pharo.fogbugz.com/f/cases/17041/We-should-be-able-to-disable-GTSpotter

But we still cannot disable/enable Spotter without hacking into KM :(
I think that sometimes it is good to think about a generic solution, but
we still can get a temporary one because everyone cannot wait 3 years
that the good one works. We can still let a flag "Remove this temporary
solution after we finish <issueNumberHere>".

> of course is still possible :)
>
> anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do “headless” it just laugh at you, but is doable in the not-so-long term.
>
> Esteban
>

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

stepharo

Re: About Pharo 60

In reply to this post by CyrilFerlicot

Thanks Cyril

Now we have to check what is synectique specific from what should be
pushed to Pharo.

> Since we moved to a Seaside application not so long after I joined
> Synectique we only disable some basic things.
>
> If I don't say anything wrong here is what we did:
> - Remove repositories containing "Synectique" in the name
> - Reset all passwords (MCHttpRepository clearPasswords)
> - Install a custom world menu (WorldState desktopMenuPragmaKeyword: 'XXX')
> - Remove Halos (At the time I created an issue to be able to do `Morph
> halosEnabled: false`, but it would be useful to make that a setting)
> - Remove Spotter ((KMRepository default globalCategories detect: [ :each
> | each isKindOf: GTSpotterGlobalShortcut ]) allEntries keymaps do:
> #disable)
> - Usman also added a transparent Morph that could catch some shortcuts I
> think and that would block some actions. We could disabled it with a
> dialog and a password.
>
>> Now this is important to see that if people for which the value is high
>> do not work on something
>> why others would do it.
>>> When I improved the deployment of Synectique Tools I asked to get a
>>> simple way to disable Spotter via a setting but I got as answer "No
>>> because you can do it by removing a global shortcut so it is not
>>> needed.".
>> I do not know how to do it either. So we should document that.
> What I did:
>
> (KMRepository default globalCategories detect: [ :each | each isKindOf:
> GTSpotterGlobalShortcut ]) allEntries keymaps do: #disable
>
> Ugly I know but it worked and was only called once in the CI.
>
>>> People in companies don't have the time to learn how shortcuts work and
>>> how to remove one without impacting something else. And they don't have
>>> the time to check Spotter code to know how it is call.
>>>
>>> If the image is able to have a deployment mode then I don't care how
>>> Spotter is disabled (setting or removing a shortcut). But for now we
>>> don't have it. :)
>> No you should care because one day you will come with a new requirement :)
>> I understand what you mean but the point is that Pharo is our common
>> architecture
>> so we should just all pay attention and we cannot ask people to do
>> everything because
>> we all have 24 h a day. So we should be smart, share and build together.
>>

EstebanLM

Re: About Pharo 60

In reply to this post by CyrilFerlicot

> On 28 Aug 2016, at 00:55, Cyril Ferlicot D. <[hidden email]> wrote:
>
> Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit :
>> yes, some years ago I made a package for this.
>> later Ben tried something similar with the user manager.
>> none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that.
>>
>
> I checked the issue tracker and it was closed because people though that
> we need a better way to disable shortcuts in general and that it is not
> specific to Spotter.
>
> https://pharo.fogbugz.com/f/cases/17041/We-should-be-able-to-disable-GTSpotter
>
> But we still cannot disable/enable Spotter without hacking into KM :(
> I think that sometimes it is good to think about a generic solution, but
> we still can get a temporary one because everyone cannot wait 3 years
> that the good one works. We can still let a flag "Remove this temporary
> solution after we finish <issueNumberHere>”.

ok, I will re-open it because this is not about shourtcuts, is about enabling or disabling a tool. The fact that this tool is called with a shortcut is just a detail… and also is incomplete: a good setting should also remove spotter from world menu, for example.

Esteban

>
>
>> of course is still possible :)
>>
>> anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do “headless” it just laugh at you, but is doable in the not-so-long term.
>>
>> Esteban
>>
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>

Tudor Girba-2

Re: About Pharo 60

In reply to this post by EstebanLM

Hi,

The answer was that Spotter is not different in any way than any other global shortcut. This means that if we want to have an interactive solution, we should do it at the level of the Keymapping framework not at the level of individual tools.

In the meantime, how do we manage this? Inspect:

KMRepository default

If you want to remove all of them you can do:

KMRepository default globalCategories removeAll

Given that producing an end-user image should rely on a script, I think this solution pragmatic enough.

Or do I miss something?

Cheers,

Doru

On Aug 27, 2016, at 2:32 PM, Esteban Lorenzano <[hidden email]> wrote:

yes, some years ago I made a package for this.
later Ben tried something similar with the user manager.
none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that.

of course is still possible :)

anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do “headless” it just laugh at you, but is doable in the not-so-long term.

Esteban

On 27 Aug 2016, at 13:39, Cyril Ferlicot D. <[hidden email]> wrote:

Le 27/08/2016 à 13:18, stepharo a écrit :

YES!!!

Do you know how Settings works?
We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system
should be
defined in way that it can be set just as a setting.
We should not have

World ....
User current = ifTrue

But

World use: userSetting

and World should handle it.
There is way more to do :)
When you deploy on linux you should be able to say beSilent to the
system (do not write on places that you cannot).
Valentin works on it and we should continue

Stef

The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."