Re: [Pharo-dev] Updated syntax postcard

[Tudor Girba]

Excellent work!

Doru



> On Jun 1, 2018, at 11:56 PM, Pavel Krivanek  wrote:
> 
> Thanks to all for feedback. Updated.
> 
> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg
> 
> Related can be found here: 
> https://github.com/pavel-krivanek/pharoMaterials/tree/master/postcard
> 
> -- Pavel
> 
> 2018-06-01 13:20 GMT+02:00 Peter Uhnák :
> This is a really nice overview!
> 
> Two "p" characters are rendered weirdly for me (Chrome 66), but the remaining 
> "p"s are good. The zoom level doesn't matter.
> 
> 
> Could you please include keyword message with multiple parameters? From my 
> teaching this always confuses people. :)
> 
> And if you want it to be really complete (maybe you've just missed these): 
> annotation for block (only block parameter is annotated), and mayhaps 
> definition of unary/binary message?
> 
> Peter
> 
> On Fri, Jun 1, 2018 at 12:56 PM, Pavel Krivanek  
> wrote:
> Hi,
> 
> for the Wikipedia article I prepared an updated version of Phar syntax 
> postcard:
> 
> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg
> 
> Cheers,
> -- Pavel
> 
> 

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

"We cannot reach the flow of things unless we let go."

[Pharo-dev] Iceberg "Duplicated project!"

[Martin McClure]

On a Pharo7, Linux, from yesterday:
Build information:
Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9
(32 Bit)

During an Iceberg load of a Metacello baseline, I get a dialog

Duplicated project!
There is already a project "OSSubprocess" in this installation.

It's true that I do have a Git clone of OSSubprocess in my
pharo-local/iceberg directory, since this is the second image I've
loaded into, but before it's always just used the already-cloned repo
rather than trying to create a new one.

Any ideas on what the correct behavior currently is (for the system, and
for me) at this point?

Thanks,
-Martin

Re: [Pharo-dev] Updated syntax postcard

[Pavel Krivanek]

Thanks to all for feedback. Updated.

https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg

Related can be found here:
https://github.com/pavel-krivanek/pharoMaterials/tree/master/postcard

-- Pavel

2018-06-01 13:20 GMT+02:00 Peter Uhnák :

> This is a really nice overview!
>
> Two "p" characters are rendered weirdly for me (Chrome 66), but the
> remaining "p"s are good. The zoom level doesn't matter.
>
>
> Could you please include keyword message with multiple parameters? From my
> teaching this always confuses people. :)
>
> And if you want it to be really complete (maybe you've just missed these):
> annotation for block (only block parameter is annotated), and mayhaps
> definition of unary/binary message?
>
> Peter
>
> On Fri, Jun 1, 2018 at 12:56 PM, Pavel Krivanek 
> wrote:
>
>> Hi,
>>
>> for the Wikipedia article I prepared an updated version of Phar syntax
>> postcard:
>>
>> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_sy
>> ntax_postcard.svg
>>
>> Cheers,
>> -- Pavel
>>
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #1002: 22038-Replace-World-Menu-by-Menu-bar

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1002 was: SUCCESS.

The Pull Request #1470 was integrated: "22038-Replace-World-Menu-by-Menu-bar"
Pull request url: https://github.com/pharo-project/pharo/pull/1470

Issue Url: https://pharo.fogbugz.com/f/cases/22038
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1002/

[Pharo-dev] [Pharo 7.0-dev] Build #1001: 21215-FileReference--nextVersion-should-works-on-folders-too

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1001 was: SUCCESS.

The Pull Request #1433 was integrated: 
"21215-FileReference--nextVersion-should-works-on-folders-too"
Pull request url: https://github.com/pharo-project/pharo/pull/1433

Issue Url: https://pharo.fogbugz.com/f/cases/21215
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1001/

[Pharo-dev] [Pharo 7.0-dev] Build #1000: 14063-clean-up-definitionForNautilus

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1000 was: SUCCESS.

The Pull Request #1466 was integrated: "14063-clean-up-definitionForNautilus"
Pull request url: https://github.com/pharo-project/pharo/pull/1466

Issue Url: https://pharo.fogbugz.com/f/cases/14063
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1000/

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Denis Kudriashov]

Looks like Pharo 7 will be the most impressive release in all aspects of
system:).

About pragmas:
I believe we should move to Commander with first class commands.
It requires to create command classes for all menu items. For example "Save
image":

SaveImageCommand>>execute

Smalltalk
snapshot: true
andQuit: false.

SaveImageCommand class>>worldMenuActivation

^CmdContextMenuCommandActivation byRootGroupItemFor: *CmdWorldMenuContext *

SaveImageCommand class>>globalShortcutActivation


^CmdShortcutCommandActivation by: $s meta shift for: *CmdWorldMenuContext *

It will bring reusable commands which activation can be extended


2018-06-01 20:23 GMT+03:00 Peter Uhnák :

> On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris 
> wrote:
>
>> Peter Uhnák wrote
>> > Pharo adds 25px margin on all sides of a full-screen window.
>>
>> Good point. I wonder why that's the case!
>
>
> According to the github issue discussion, this is the case.
>
>
>> Peter Uhnák wrote
>> > it provides the most important/common options that user needs
>>
>> Ah! Good to know and interesting, but presumably very subjective.
>
>
> For sure. But for an end-user application it is my responsibility to
> figure out the UI/UX.
>
>
>> Although it is currently flexible, I don't think we have that now.
>>
>
> The pragma collection can be filtered, but it is not used by the code, so
> it is all-or-nothing, not very flexible. I think this is for future
> iterations.
>
> Peter Uhnák wrote
>> > very often I find myself having to move windows, just so I can expose a
>> > piece of desktop to click on.
>>
>> Why don't you use the 25px margin?! ha ha j/k
>>
>
> This applies to fullscreen only. It doesn't apply when you manually move a
> window to this space.
> And for fullscreen, I often have the margin disabled. So that's why. :)
>
> Peter
>

[Pharo-dev] [Pharo 7.0-dev] Build #999: 22036-ClassBuilderWarning--Error--Hierarchy----clean-some-unused-

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #999 was: FAILURE.

The Pull Request #1469 was integrated: 
"22036-ClassBuilderWarning--Error--Hierarchyclean-some-unused-"
Pull request url: https://github.com/pharo-project/pharo/pull/1469

Issue Url: https://pharo.fogbugz.com/f/cases/22036
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/999/

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Peter Uhnák]

On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris 
wrote:

> Peter Uhnák wrote
> > Pharo adds 25px margin on all sides of a full-screen window.
>
> Good point. I wonder why that's the case!


According to the github issue discussion, this is the case.


> Peter Uhnák wrote
> > it provides the most important/common options that user needs
>
> Ah! Good to know and interesting, but presumably very subjective.


For sure. But for an end-user application it is my responsibility to figure
out the UI/UX.


> Although it is currently flexible, I don't think we have that now.
>

The pragma collection can be filtered, but it is not used by the code, so
it is all-or-nothing, not very flexible. I think this is for future
iterations.

Peter Uhnák wrote
> > very often I find myself having to move windows, just so I can expose a
> > piece of desktop to click on.
>
> Why don't you use the 25px margin?! ha ha j/k
>

This applies to fullscreen only. It doesn't apply when you manually move a
window to this space.
And for fullscreen, I often have the margin disabled. So that's why. :)

Peter

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Sean P. DeNigris]

Peter Uhnák wrote
> Pharo adds 25px margin on all sides of a full-screen window.

Good point. I wonder why that's the case! Maybe as you later pointed out to
keep some desktop available for clicking.



Peter Uhnák wrote
> it provides the most important/common options that user needs

Ah! Good to know and interesting, but presumably very subjective. This would
seem to point to the need for total individual customizability of the World
Menu. Although it is currently flexible, I don't think we have that now.


Peter Uhnák wrote
> very often I find myself having to move windows, just so I can expose a
> piece of desktop to click on.

Why don't you use the 25px margin?! ha ha j/k
Seriously though, thanks for the explanation it was very helpful. As long as
the proposal can be turned on and off it sounds good.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Guillermo Polito]

On Fri, Jun 1, 2018 at 5:11 PM, Peter Uhnák  wrote:

> Hi,
>
> @Cyril
>
> I don't know if it should be in the SettingBrowser since Pharo currently
>> comes with only one menu (if someone know how to implement a new one it
>> will be easy for him to find the option to change the pragma of the
>> MenuBarMorph), but the pragma should be parametrizable in any case.
>
>
> Adding a new pragma is not a problem, you can use whatever name you want
> (see e.g. worldMenuExample pragma), but there is no way to tell Pharo to
> use this instead of the default one.
>


>
> I don't know if it should be in the SettingBrowser since Pharo currently comes
>> with only one menu
>
>
> Oh, never mind. I just found out that this is already in place, in
> WorldState class>>desktopMenuPragmaKeyword:. I don't know how I managed
> to miss this in the past.
> So if the new menu bar just uses this (WorldState 
> class>>discoveredMenuPragmaKeyword),
> or uses a similar mechanism (so the menus can differ, which would be also
> nice), then all is well.
>

Well, actually we are right now doing this:

open
"self open"

self new
menuBarItems: WorldState new menuBuilder menuSpec items;
open.

So the menu bar uses the menuBuilder used by the system, which is hiding
the pragma and everything from us :)


>
> I'll rephrase, we have ideas to manage all those problems but how do we
>> implement it? Currently there is no widget to do that and sadly we don't
>> have enough time to create them :(
>
>
> I don't know about menu morph, but the bottom menu can handle overflow,
> can that be used for the time-being?
>

Well, one thing is to overflow like the bottom bar (growing so all items
fit). But I'd like to have a solution (now for this iteration) where
overflowing items are hidden and shown in a "..." button or a hamburguer
button.


>
> @Sean:
>
> Were these projects where you were the only user?
>
>
> No.
>
> For experienced users, I struggle to see how "Navigate over to Xyz which
>> takes up screen real estate" is better than "click wherever the cursor 
>> happens
>> to be"
>
>
> Pharo adds 25px margin on all sides of a full-screen window. This is
> enough to add menu to each side. So in fact Pharo already wastes 4x as much
> space to do what you want.
> Secondly, my menu doesn't match the world menu, it provides the most
> important/common options that user needs; so yes, it is faster, because it
> is one or two clicks instead of going through items that are not relevant
> to the user.
> Finally, even if I didn't consider full screen, very often I find myself
> having to move windows, just so I can expose a piece of desktop to click on.
>
> Please don't forget that some Pharo applications are meant for
> (non-programmer) end users, and not for (Pharo) developers.
>
> But don't see a problem with adding a checkbox to settings "Menu bar [x]".
> There is already such a setting for the bottom task bar ("Taskbar...").
>
> Peter
>
> On Fri, Jun 1, 2018 at 4:27 PM, Alistair Grant 
> wrote:
>
>> Hi Cyril,
>>
>> On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
>> > On 01/06/2018 15:18, Alistair Grant wrote:
>> >
>> > Personally, I would like to have display strategies for the WorldMenu
>> > and the user could select the one he likes (because nobody will agree on
>> > UI).
>> > For example:
>> > - Menu bar strategy
>> > - World menu strategy
>> > - Start button strategy
>> > - Composite strategy to have multiple ones
>> >
>> > Now it is simple to do the two first, but I will probably not have the
>> > time to implement the "Start button" one.
>>
>> Fair enough. (I haven't had time to do much of anything recently)
>>
>>
>>
>> On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
>> > On 01/06/2018 15:25, Peter Uhn??k wrote:
>> > >
>> > > Also, is it (easily) possible to configure the position of the menu?
>> > > Both top/down, as well as RTL and LTR direction (or right-aligned LTR)
>> > > which I mentioned for the bottom menu in an earlier github discussion.
>> > >
>> >
>> > For now I don't think so. I think it would be cool to integrate this
>> > first version then everyone can try to improve it.
>>
>> +1 (to integrating a first version and iterating)
>>
>> Cheers,
>> Alistair
>>
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Peter Uhnák]

Hi,

@Cyril

I don't know if it should be in the SettingBrowser since Pharo currently
> comes with only one menu (if someone know how to implement a new one it
> will be easy for him to find the option to change the pragma of the
> MenuBarMorph), but the pragma should be parametrizable in any case.


Adding a new pragma is not a problem, you can use whatever name you want
(see e.g. worldMenuExample pragma), but there is no way to tell Pharo to
use this instead of the default one.

I don't know if it should be in the SettingBrowser since Pharo currently comes
> with only one menu


Oh, never mind. I just found out that this is already in place, in
WorldState class>>desktopMenuPragmaKeyword:. I don't know how I managed to
miss this in the past.
So if the new menu bar just uses this (WorldState
class>>discoveredMenuPragmaKeyword), or uses a similar mechanism (so the
menus can differ, which would be also nice), then all is well.

I'll rephrase, we have ideas to manage all those problems but how do we
> implement it? Currently there is no widget to do that and sadly we don't
> have enough time to create them :(


I don't know about menu morph, but the bottom menu can handle overflow, can
that be used for the time-being?

@Sean:

Were these projects where you were the only user?


No.

For experienced users, I struggle to see how "Navigate over to Xyz which
> takes up screen real estate" is better than "click wherever the cursor happens
> to be"


Pharo adds 25px margin on all sides of a full-screen window. This is enough
to add menu to each side. So in fact Pharo already wastes 4x as much space
to do what you want.
Secondly, my menu doesn't match the world menu, it provides the most
important/common options that user needs; so yes, it is faster, because it
is one or two clicks instead of going through items that are not relevant
to the user.
Finally, even if I didn't consider full screen, very often I find myself
having to move windows, just so I can expose a piece of desktop to click on.

Please don't forget that some Pharo applications are meant for
(non-programmer) end users, and not for (Pharo) developers.

But don't see a problem with adding a checkbox to settings "Menu bar [x]".
There is already such a setting for the bottom task bar ("Taskbar...").

Peter

On Fri, Jun 1, 2018 at 4:27 PM, Alistair Grant 
wrote:

> Hi Cyril,
>
> On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
> > On 01/06/2018 15:18, Alistair Grant wrote:
> >
> > Personally, I would like to have display strategies for the WorldMenu
> > and the user could select the one he likes (because nobody will agree on
> > UI).
> > For example:
> > - Menu bar strategy
> > - World menu strategy
> > - Start button strategy
> > - Composite strategy to have multiple ones
> >
> > Now it is simple to do the two first, but I will probably not have the
> > time to implement the "Start button" one.
>
> Fair enough. (I haven't had time to do much of anything recently)
>
>
>
> On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
> > On 01/06/2018 15:25, Peter Uhn??k wrote:
> > >
> > > Also, is it (easily) possible to configure the position of the menu?
> > > Both top/down, as well as RTL and LTR direction (or right-aligned LTR)
> > > which I mentioned for the bottom menu in an earlier github discussion.
> > >
> >
> > For now I don't think so. I think it would be cool to integrate this
> > first version then everyone can try to improve it.
>
> +1 (to integrating a first version and iterating)
>
> Cheers,
> Alistair
>
>
>

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> - the old situation (world menu is click on background) + new task/open
> window widget 

If there's a "preserve the status quo" option (e.g. World Menu behavior
unchanged and no toolbar), I'm happy!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Alistair Grant]

Hi Cyril,

On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
> On 01/06/2018 15:18, Alistair Grant wrote:
> 
> Personally, I would like to have display strategies for the WorldMenu
> and the user could select the one he likes (because nobody will agree on
> UI).
> For example:
> - Menu bar strategy
> - World menu strategy
> - Start button strategy
> - Composite strategy to have multiple ones
> 
> Now it is simple to do the two first, but I will probably not have the
> time to implement the "Start button" one.

Fair enough. (I haven't had time to do much of anything recently)



On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
> On 01/06/2018 15:25, Peter Uhn??k wrote:
> > 
> > Also, is it (easily) possible to configure the position of the menu?
> > Both top/down, as well as RTL and LTR direction (or right-aligned LTR)
> > which I mentioned for the bottom menu in an earlier github discussion.
> > 
> 
> For now I don't think so. I think it would be cool to integrate this
> first version then everyone can try to improve it.

+1 (to integrating a first version and iterating)

Cheers,
Alistair

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Sven Van Caekenberghe]

But if we can have 

- the old situation (world menu is click on background) + new task/open window 
widget 
- the new task/open window widget + optional 1st special 'start' button (and 
keep world menu is click on background)
- the new task/open window widget + the new menu bar widget

that would then cover all cases, no ?

> On 1 Jun 2018, at 15:58, Sean P. DeNigris  wrote:
> 
> Peter Uhnák wrote
>> I really love this idea. I've already added (hacked together) something
>> similar for some of my projects so I am happy to see this is going into
>> Pharo.
> 
> Were these projects where you were the only user? I'm very leery of this
> change. For experienced users, I struggle to see how "Navigate over to Xyz
> which takes up screen real estate" is better than "click wherever the cursor
> happens to be". Could the setting actually be between the current behavior
> and the new, and not variations on something new that many existing users
> may not want/benefit from?
> 
> The new user argument makes some sense, but of all the difficulties I had
> learning Squeak/Pharo I for one never found the World Menu confusing as a
> new user. I guess we have to defer to people who deal more directly with
> newbies on that point…
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Sean P. DeNigris]

Peter Uhnák wrote
> I really love this idea. I've already added (hacked together) something
> similar for some of my projects so I am happy to see this is going into
> Pharo.

Were these projects where you were the only user? I'm very leery of this
change. For experienced users, I struggle to see how "Navigate over to Xyz
which takes up screen real estate" is better than "click wherever the cursor
happens to be". Could the setting actually be between the current behavior
and the new, and not variations on something new that many existing users
may not want/benefit from?

The new user argument makes some sense, but of all the difficulties I had
learning Squeak/Pharo I for one never found the World Menu confusing as a
new user. I guess we have to defer to people who deal more directly with
newbies on that point…



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Cyril Ferlicot D.]

On 01/06/2018 15:25, Peter Uhnák wrote:
> Hi,
> 
> I really love this idea. I've already added (hacked together) something
> similar for some of my projects so I am happy to see this is going into
> Pharo.
> 
>> - Make it parametrizable to allow users to build a bar with their own menu 
>> builder
> 
> I would love if it was possible to somewhere (Settings?) just specify a
> pragma that should be used for the construction of the menu... or
> perhaps even a list of pragmas. That way the existing mechanism can be
> simply reused and custom menus can be created just as easily.
> I think this should be very easy to add.
> 

I don't know if it should be in the SettingBrowser since Pharo currently
comes with only one menu (if someone know how to implement a new one it
will be easy for him to find the option to change the pragma of the
MenuBarMorph), but the pragma should be parametrizable in any case.

> I would really love to have this option also for the regular world menu,
> but I didn't find a way to easily achieve that.
> 
>>  - What do we do when Pharo is not wide enough?
> 
> Hamburger menu?

I'll rephrase, we have ideas to manage all those problems but how do we
implement it? Currently there is no widget to do that and sadly we don't
have enough time to create them :(

> 
>>  - What to do when a window is dragged behind?
> 
> Currently you cannot drag window above the top side (which I've learned
> only now :-D ), so the constraint would just move a bit lower?

Yes, but for now when can detect a drop on the menu bar only if the
cursor is over the MenubarMorph. If the user drop the window by dragging
the bottom, the top of the windows will be under the MenubarMorph.

> 
> Also, is it (easily) possible to configure the position of the menu?
> Both top/down, as well as RTL and LTR direction (or right-aligned LTR)
> which I mentioned for the bottom menu in an earlier github discussion.
> 

For now I don't think so. I think it would be cool to integrate this
first version then everyone can try to improve it.

> Peter
> 
> 


-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Cyril Ferlicot D.]

On 01/06/2018 15:18, Alistair Grant wrote:
> Hi Guille & Cyril,
> 
> Thanks for this.  Along with being able to maximise windows
> completely, making the task-bar distinct at the bottom, these are
> great changes.
> 

Yes, I did not see the problem  because I use backgrounds and it was
visible :)

> Instead of a menu bar at the top, which takes quite a bit of space,
> and as mentioned may not fit on a small screen (especially if
> applications add entries), how about a "Start" button in the task-bar
> that pops up the menu a-la Windows?  I'm not tied to the name "Start",
> it could just be an earth icon, which would save space.   (This is
> actually how I interpreted Cyril's original suggestion)
> 

Personally, I would like to have display strategies for the WorldMenu
and the user could select the one he likes (because nobody will agree on
UI).
For example:
- Menu bar strategy
- World menu strategy
- Start button strategy
- Composite strategy to have multiple ones

Now it is simple to do the two first, but I will probably not have the
time to implement the "Start button" one.

> Cheers,
> Alistair
> 
> 
> 


-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-dev] [Pharo 7.0-dev] Build #998: 20324-Handy-file-automatic-numbering

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #998 was: SUCCESS.

The Pull Request #1460 was integrated: "20324-Handy-file-automatic-numbering"
Pull request url: https://github.com/pharo-project/pharo/pull/1460

Issue Url: https://pharo.fogbugz.com/f/cases/20324
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/998/

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Torsten Bergmann]

>Guille & Cyril wrote>
> > Since some decades now the default way to display a menu in applications
> > is to have a bar at the top of the windows. 


Alistair wrote
>> Instead of a menu bar at the top, which takes quite a bit of space,
>> and as mentioned may not fit on a small screen how about a "Start" 
>button in the task-bar that pops up the menu a-la Windows


So this basically reduces to the two UI options:

 1. Should Pharo look like an application (and have the menu at the top)

 2. Should Pharo look like an OS itself (with a primary "Start" menu in the 
taskbar as on Windows)

Maybe we should support both styles using a setting.

Bye
T.

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Peter Uhnák]

>   - For those that "get it" they try to do it with right click (Of course,
it looks like a context menu!) and that does not work

I thought that this was due to be swapped for Pharo 7? Was that idea
scraped?

Peter

On Fri, Jun 1, 2018 at 3:18 PM, Alistair Grant 
wrote:

> Hi Guille & Cyril,
>
> On 1 June 2018 at 14:22, Cyril Ferlicot D. 
> wrote:
> > Hi everyone,
> >
> > With Guille we are trying to improve the usability of the WorldMenu.
> >
> > The world menu is by large un-intuitive:
> >  - Users are not used to click on a background to open a menu
> >  - For those that "get it" they try to do it with right click (Of
> > course, it looks like a context menu!) and that does not work
> >
> > Since some decades now the default way to display a menu in applications
> > is to have a bar at the top of the windows. We should change that world
> > menu by a menu bar like any application. That will lower the entrance
> > barrier to new users, at the cost of having to move the cursor to the
> > top to look for the menu...
> >
> > You can find here a PR that add the WorldMenu as a top bar to Pharo and
> > reorganize it:
> >
> > https://github.com/pharo-project/pharo/pull/1470
> >
> > See screen in the PR.
> >
> > It still have room for improvements but we think it's stable enough for
> > integration in Pharo.
> >
> > Missing features:
> > - What do we do when Pharo is not wide enough?
> > - What to do when a window is dragged behind?
> > - Make it parametrizable to allow users to build a bar with their own
> > menu builder
> > - Add shortcuts to open the menu windows like (maybe)
> > - Update it when we change the font size (this is a general Pharo
> problem)
> >
> > Feedback is welcome.
>
> Thanks for this.  Along with being able to maximise windows
> completely, making the task-bar distinct at the bottom, these are
> great changes.
>
> Instead of a menu bar at the top, which takes quite a bit of space,
> and as mentioned may not fit on a small screen (especially if
> applications add entries), how about a "Start" button in the task-bar
> that pops up the menu a-la Windows?  I'm not tied to the name "Start",
> it could just be an earth icon, which would save space.   (This is
> actually how I interpreted Cyril's original suggestion)
>
> Cheers,
> Alistair
>
>
>
> > Related issue:
> > https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar
> >
> > Guille & Cyril
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
>
>

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Peter Uhnák]

Hi,

I really love this idea. I've already added (hacked together) something
similar for some of my projects so I am happy to see this is going into
Pharo.

> - Make it parametrizable to allow users to build a bar with their own menu
builder

I would love if it was possible to somewhere (Settings?) just specify a
pragma that should be used for the construction of the menu... or perhaps
even a list of pragmas. That way the existing mechanism can be simply
reused and custom menus can be created just as easily.
I think this should be very easy to add.

I would really love to have this option also for the regular world menu,
but I didn't find a way to easily achieve that.

>  - What do we do when Pharo is not wide enough?

Hamburger menu?

>  - What to do when a window is dragged behind?

Currently you cannot drag window above the top side (which I've learned
only now :-D ), so the constraint would just move a bit lower?

Also, is it (easily) possible to configure the position of the menu? Both
top/down, as well as RTL and LTR direction (or right-aligned LTR) which I
mentioned for the bottom menu in an earlier github discussion.

Peter



On Fri, Jun 1, 2018 at 2:22 PM, Cyril Ferlicot D. 
wrote:

> Hi everyone,
>
> With Guille we are trying to improve the usability of the WorldMenu.
>
> The world menu is by large un-intuitive:
>  - Users are not used to click on a background to open a menu
>  - For those that "get it" they try to do it with right click (Of
> course, it looks like a context menu!) and that does not work
>
> Since some decades now the default way to display a menu in applications
> is to have a bar at the top of the windows. We should change that world
> menu by a menu bar like any application. That will lower the entrance
> barrier to new users, at the cost of having to move the cursor to the
> top to look for the menu...
>
> You can find here a PR that add the WorldMenu as a top bar to Pharo and
> reorganize it:
>
> https://github.com/pharo-project/pharo/pull/1470
>
> See screen in the PR.
>
> It still have room for improvements but we think it's stable enough for
> integration in Pharo.
>
> Missing features:
> - What do we do when Pharo is not wide enough?
> - What to do when a window is dragged behind?
> - Make it parametrizable to allow users to build a bar with their own
> menu builder
> - Add shortcuts to open the menu windows like (maybe)
> - Update it when we change the font size (this is a general Pharo problem)
>
> Feedback is welcome.
>
> Related issue:
> https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar
>
> Guille & Cyril
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Alistair Grant]

Hi Guille & Cyril,

On 1 June 2018 at 14:22, Cyril Ferlicot D.  wrote:
> Hi everyone,
>
> With Guille we are trying to improve the usability of the WorldMenu.
>
> The world menu is by large un-intuitive:
>  - Users are not used to click on a background to open a menu
>  - For those that "get it" they try to do it with right click (Of
> course, it looks like a context menu!) and that does not work
>
> Since some decades now the default way to display a menu in applications
> is to have a bar at the top of the windows. We should change that world
> menu by a menu bar like any application. That will lower the entrance
> barrier to new users, at the cost of having to move the cursor to the
> top to look for the menu...
>
> You can find here a PR that add the WorldMenu as a top bar to Pharo and
> reorganize it:
>
> https://github.com/pharo-project/pharo/pull/1470
>
> See screen in the PR.
>
> It still have room for improvements but we think it's stable enough for
> integration in Pharo.
>
> Missing features:
> - What do we do when Pharo is not wide enough?
> - What to do when a window is dragged behind?
> - Make it parametrizable to allow users to build a bar with their own
> menu builder
> - Add shortcuts to open the menu windows like (maybe)
> - Update it when we change the font size (this is a general Pharo problem)
>
> Feedback is welcome.

Thanks for this.  Along with being able to maximise windows
completely, making the task-bar distinct at the bottom, these are
great changes.

Instead of a menu bar at the top, which takes quite a bit of space,
and as mentioned may not fit on a small screen (especially if
applications add entries), how about a "Start" button in the task-bar
that pops up the menu a-la Windows?  I'm not tied to the name "Start",
it could just be an earth icon, which would save space.   (This is
actually how I interpreted Cyril's original suggestion)

Cheers,
Alistair



> Related issue:
> https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar
>
> Guille & Cyril
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>

Re: [Pharo-dev] Updated syntax postcard

[Esteban A. Maringolo]

Thank you! It's really nice!

On 01/06/2018 07:56, Pavel Krivanek wrote:
> Hi,
> 
> for the Wikipedia article I prepared an updated version of Phar syntax
> postcard:
> 
> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg
> 
> Cheers,
> -- Pavel

-- 
Esteban A. Maringolo

[Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Cyril Ferlicot D.]

Hi everyone,

With Guille we are trying to improve the usability of the WorldMenu.

The world menu is by large un-intuitive:
 - Users are not used to click on a background to open a menu
 - For those that "get it" they try to do it with right click (Of
course, it looks like a context menu!) and that does not work

Since some decades now the default way to display a menu in applications
is to have a bar at the top of the windows. We should change that world
menu by a menu bar like any application. That will lower the entrance
barrier to new users, at the cost of having to move the cursor to the
top to look for the menu...

You can find here a PR that add the WorldMenu as a top bar to Pharo and
reorganize it:

https://github.com/pharo-project/pharo/pull/1470

See screen in the PR.

It still have room for improvements but we think it's stable enough for
integration in Pharo.

Missing features:
- What do we do when Pharo is not wide enough?
- What to do when a window is dragged behind?
- Make it parametrizable to allow users to build a bar with their own
menu builder
- Add shortcuts to open the menu windows like (maybe)
- Update it when we change the font size (this is a general Pharo problem)

Feedback is welcome.

Related issue:
https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar

Guille & Cyril

-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] Updated syntax postcard

[Sean P. DeNigris]

Pavel Krivanek-3 wrote
> syntax postcard:

Ha ha, I love the real-postcard look!

Two things:
1. "metod name" at the top is missing an $h
2. Might it be worthwhile to add something like "compile-time" to "literal
array" to better distinguish from "array generate at runtime"?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Updated syntax postcard

[Sven Van Caekenberghe]

Cool & beautiful !

The $p are good for me.

I agree with the other remarks.

I would love a big A4 landscape version.

> On 1 Jun 2018, at 13:20, Peter Uhnák  wrote:
> 
> This is a really nice overview!
> 
> Two "p" characters are rendered weirdly for me (Chrome 66), but the remaining 
> "p"s are good. The zoom level doesn't matter.
> 
> 
> Could you please include keyword message with multiple parameters? From my 
> teaching this always confuses people. :)
> 
> And if you want it to be really complete (maybe you've just missed these): 
> annotation for block (only block parameter is annotated), and mayhaps 
> definition of unary/binary message?
> 
> Peter
> 
> On Fri, Jun 1, 2018 at 12:56 PM, Pavel Krivanek  
> wrote:
> Hi,
> 
> for the Wikipedia article I prepared an updated version of Phar syntax 
> postcard:
> 
> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg
> 
> Cheers,
> -- Pavel
> 

[Pharo-dev] [Pharo 7.0-dev] Build #996: 20324-Handy-file-automatic-numbering

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #996 was: FAILURE.

The Pull Request #1460 was integrated: "20324-Handy-file-automatic-numbering"
Pull request url: https://github.com/pharo-project/pharo/pull/1460

Issue Url: https://pharo.fogbugz.com/f/cases/20324
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/996/

Re: [Pharo-dev] Updated syntax postcard

[Peter Uhnák]

This is a really nice overview!

Two "p" characters are rendered weirdly for me (Chrome 66), but the
remaining "p"s are good. The zoom level doesn't matter.


Could you please include keyword message with multiple parameters? From my
teaching this always confuses people. :)

And if you want it to be really complete (maybe you've just missed these):
annotation for block (only block parameter is annotated), and mayhaps
definition of unary/binary message?

Peter

On Fri, Jun 1, 2018 at 12:56 PM, Pavel Krivanek 
wrote:

> Hi,
>
> for the Wikipedia article I prepared an updated version of Phar syntax
> postcard:
>
> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_
> syntax_postcard.svg
>
> Cheers,
> -- Pavel
>

[Pharo-dev] Updated syntax postcard

[Pavel Krivanek]

Hi,

for the Wikipedia article I prepared an updated version of Phar syntax
postcard:

https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg

Cheers,
-- Pavel

[Pharo-dev] [Pharo 7.0-dev] Build #995: 20324-Handy-file-automatic-numbering

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #995 was: FAILURE.

The Pull Request #1460 was integrated: "20324-Handy-file-automatic-numbering"
Pull request url: https://github.com/pharo-project/pharo/pull/1460

Issue Url: https://pharo.fogbugz.com/f/cases/20324
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/995/

Re: [Pharo-dev] curious behaviour - disappearing variable scope

[Sven Van Caekenberghe]

There is also #repeat for 'infinite' loops

> On 1 Jun 2018, at 10:18, Ben Coman  wrote:
> 
> 
> 
> On 1 June 2018 at 15:23, Ben Coman  wrote:
> 
> 
> On 1 June 2018 at 14:59, Ben Coman  wrote:
> I'm curious about the following behaviour...
> 
> "In Playground, first evaluate..."
> s := Semaphore new.
> [[  s wait.   
> Transcript crShow: 'x' 
>  ] whileTrue 
> ] forkAt: 41.
> 
> Apologies for my brain freeze. It should have been...
> s := Semaphore new.
> [ [   s wait.
>   Transcript crShow: 'x'.
>   true ] whileTrue 
> ] forkAt: 41.
> 
> 
> But an error around the end of the block rather than the start would have 
> been useful.
> cheers -ben
>  
> 
> "then later..."
> s signal.
> 
> ==> 'x' is seen in Transcript
> but then an error pops up "#wait was sent to nil"
> 
> So...  's'  *was*  valid and then its not?
> 
> cheers -ben
> 
>  

Re: [Pharo-dev] curious behaviour - disappearing variable scope

[Ben Coman]

On 1 June 2018 at 15:23, Ben Coman  wrote:

>
>
> On 1 June 2018 at 14:59, Ben Coman  wrote:
>
>> I'm curious about the following behaviour...
>>
>> "In Playground, first evaluate..."
>> s := Semaphore new.
>> [[  s wait.
>>
> Transcript crShow: 'x'
>>
>  ] whileTrue
>>
> ] forkAt: 41.
>>
>
Apologies for my brain freeze. It should have been...
s := Semaphore new.
[ [ s wait.
Transcript crShow: 'x'.
true ] whileTrue
] forkAt: 41.


But an error around the end of the block rather than the start would have
been useful.
cheers -ben


>
>> "then later..."
>> s signal.
>>
>> ==> 'x' is seen in Transcript
>> but then an error pops up "#wait was sent to nil"
>>
>> So...  's'  *was*  valid and then its not?
>>
>> cheers -ben
>>
>

Re: [Pharo-dev] curious behaviour - disappearing variable scope

[Ben Coman]

On 1 June 2018 at 14:59, Ben Coman  wrote:

> I'm curious about the following behaviour...
>
> "In Playground, first evaluate..."
> s := Semaphore new.
> [ [ s wait.   Transcript crShow: 'x' ] whileTrue ] fork.
>
> "then later..."
> s signal.
>
> ==> 'x' is seen in Transcript
> but then an error pops up "#wait was sent to nil"
>
> So...  's'  *was*  valid and then its not?
>
> cheers -ben
>

Sorry I got distracted.  I should have added version info...

Image
-
C:\PharoLauncher\images\Pharo-7.0.0-alpha.build.994.sha.6b52ae6.arch.32bit\Pharo-7.0.0-alpha.build.994.sha.6b52ae6.arch.32bit.image
Pharo7.0alpha
Build information:
Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9 (32
Bit)
Unnamed

Virtual Machine
---
C:\Users\Ben\Documents\Pharo\vms\70-x86\Pharo.exe
CoInterpreter VMMaker.oscog-eem.2361 uuid:
7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid:
7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018
VM: 20180416 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Apr 12 15:26:17 2018 -0700 $ CommitHash: 07c6dc3 $ Plugins:
20180416 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

Win32 built on Apr 12 2018 22:41:03 GMT Compiler: 6.4.0
VMMaker versionString VM: 20180416
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Apr 12
15:26:17 2018 -0700 $ CommitHash: 07c6dc3 $ Plugins: 20180416
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-eem.2361 uuid:
7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid:
7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018

VM as selected by PharoLauncher.

cheers -ben

Re: [Pharo-dev] server slow

[Esteban Lorenzano]

> On 1 Jun 2018, at 09:01, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 1 Jun 2018, at 03:55, Ben Coman  wrote:
>> 
>> Server access is very slow for me right now.  It took 20 seconds to bring up 
>> the directory index for... 
>> https://files.pharo.org/image
>> 
>> Is it just me?
>> cheers -ben
> 
> Right, but it *is* a directory with 3000 files …

yes, that will always be slow.
on second thought you also shouldn’t need to go there, unless some specific 
need.

Esteban

> 
> 

Re: [Pharo-dev] server slow

[Sven Van Caekenberghe]

> On 1 Jun 2018, at 03:55, Ben Coman  wrote:
> 
> Server access is very slow for me right now.  It took 20 seconds to bring up 
> the directory index for... 
> https://files.pharo.org/image
> 
> Is it just me?
> cheers -ben

Right, but it *is* a directory with 3000 files ...

Re: [Pharo-dev] Image format not recognized

[Sven Van Caekenberghe]

https://pharo.manuscript.com/f/cases/22035/Delete-PNGReadWriter-class-createAFormFrom

> On 31 May 2018, at 19:43, Sven Van Caekenberghe  wrote:
> 
> Great, so you agree that #createAFormFrom: is a candidate for removal ?
> 
>> On 31 May 2018, at 19:01, Hilaire  wrote:
>> 
>> This is what I did, But I hope this problem will not hit somewhere else.
>> 
>> 
>> Le 31/05/2018 à 18:06, Sven Van Caekenberghe a écrit :
>>> That is because that particular method (with no users in the image) uses a 
>>> deprecated class, change it to the simpler
>>> 
>>> createAFormFrom: data
>>> | error f |
>>> error := ''.
>>> f := [ self formFromStream: data readStream ] ifError:
>>> [ :a :b |
>>> error := a printString , '  ' , b printString.
>>> (StringMorph contents: error)
>>> color: Color red;
>>> imageForm ].
>>> ^ {  f. error }
>>> 
>>> but honestly, why this method and why not directly do
>>> 
>>>  self formFromStream: data readStream
>>> 
>>> swallowing errors is so/so, IMHO. Also, the return value is really unusual. 
>>> You just want the Form, right. It is not the responsibility of a system 
>>> class to do UI for you, I think.
>> 
>> -- 
>> Dr. Geo
>> http://drgeo.eu
>> 
>> 
>> 
> 

[Pharo-dev] curious behaviour - disappearing variable scope

[Ben Coman]

I'm curious about the following behaviour...

"In Playground, first evaluate..."
s := Semaphore new.
[ [ s wait.   Transcript crShow: 'x' ] whileTrue ] fork.

"then later..."
s signal.

==> 'x' is seen in Transcript
but then an error pops up "#wait was sent to nil"

So...  's'  *was*  valid and then its not?

cheers -ben

Re: [Pharo-dev] server slow

[Marcus Denker]

We really need to switch the server again to something better.

I will work on that in June.

> On 1 Jun 2018, at 03:55, Ben Coman  wrote:
> 
> Server access is very slow for me right now.  It took 20 seconds to bring up 
> the directory index for... 
> https://files.pharo.org/image 
> 
> Is it just me?
> cheers -ben
> 
> 
> 
>