Re: [Pharo-users] What is the difference between a form and a morph?

[Markus Stumptner]

Normally, there should not be an inheritance relationship between 
wrapper and wrappee, but I agree that describing Morphs as wrappers 
around Forms seems to miss the point. The notion of wrapper usually 
implies that there is little modification to the protocol of the 
wrappee, a wrapper should not need a lot of code. But Morphs are a 
completely different level of the architecture, with a large and complex 
protocol that's very different from Forms. So let's start again.


Forms are images (implemented as rectangular pixel arrays, as stated).

Morphs are the objects that describe how the graphical interface works, 
they control displaying (for which they use Forms), handling of user 
input (mouse clicks, dragging etc) and above all the internal structure 
of the interface (for example the different regions that make up a 
window on the screen are Morphs). Note that the user display side of the 
Pharo interface is handled by class DisplayScreen, which is a subclass 
of Form.  So the Morphs in the user interface display themselves by 
inserting their Forms in the proper places on the Form that is the 
internal representation of the screen.


So, as Subbu said, you don't convert Morphs to Forms, they serve 
different purposes.  Morphs (some Morphs) have instance variables that 
allow them to refer to the Form that they use for displaying.  Hope that 
helps a bit.


I note that all of this (plus some more) you can essentially get from 
the class comments of the two.


Markus

On 25/2/20 12:22 pm, Steve Quezadas wrote:

Ben,

I checked, [Form] is inherited from class [DisplayMedium]. So in
smalltalk, the inheritence pattern is:
Object -> DisplayObject -> DisplayMedium -> Form

The inheritence pattern of ImageMorph is:
Object -> Morph -> ImageMorph

One does not inherit the other and is not a wrapper, at least in Pharo8

On Sun, Feb 23, 2020 at 10:11 PM Ben Coman > wrote:


On Mon, 24 Feb 2020 at 04:31, Steve Quezadas mailto:steve...@gmail.com>> wrote:

I usually like to go through the source code to answer my own
question, but I can't tell by reading it.

[Morph], from what I understand, deals with manipulating
graphics on smalltalk. But when I use ZnEasy to get a jpeg
file, I notice that it returns a [Form] and not a [Morph] to
display a jpeg. Spec2 also wants [Form] for displaying images
rather than [Morph].

So what is the difference between a [Form] and a [Morph] since
they both seem to deal with graphics?


I don't know the exact answer, but if you review method
ImageMorph>>form
you will see that the ImageMorph is a wrapper around a Form.

So some simple differences that may be inferred.
- Many morphs are not bitmaps.
- Morphs are GUI elements, i.e. interact with mouse and keyboard
- Forms are not GUI elements
- Forms can be manipulated without displaying them.

In some other graphics system, an analogy could be putting an
image on a button and asking "what is the difference between an
'image' and a 'button' ?"

wrt Spec2, Morph is one backend that Spec2 might use to display a
Form,
or Spec2 might display the Form using a GTK widget.

cheers -ben

Re: [Pharo-users] PolyMath v1.0.2 release

[Markus Stumptner]

Thanks for keeping working on this. I have a question, how much are the 
core classes of Polymath changed beyond the original Besset classes (or, 
beyond the "PM" prefix, how much has been changed relative to those that 
come with the Visualworks distribution)?   I'm not asking about external 
bindings such as the Tensorflow stuff, just the consistency of protocols 
for internal code.  We have some long-running projects and compatibility 
across environments (beyond the obvious environment differences) is 
quite important.


Thanks
Markus

On 6/02/2020 23:49, Serge Stinckwich wrote:

Dear all,

we are happy to announce the release of PolyMath 1.0.2, the
computational framework for Pharo. This release works on Pharo 7.0 and 
Pharo 8.0. All the 815 tests and the CI are green on MacOs, Windows 
and Linux :-)


Please find more information about the project here:
https://github.com/PolyMathOrg/PolyMath 



Changelog of modifications since version 1.0.1 is available here:
https://github.com/PolyMathOrg/PolyMath/milestone/4?closed=1

You can install the 1.0.2 version in a fresh Pharo 7.0&8.0 with the
following code snippet:

Metacello new
repository: 'github://PolyMathOrg/PolyMath:v1.0.2/src';
baseline: 'PolyMath';
load

You can join the dev team on #polymath channel for weekly meetings on 
Thursday. We are looking for more people for tests and contributions.


I'm starting a small experiment. If you want to support me working on 
PolyMath or others of my project like Tensorflow Pharo bindings, you 
can be one of my github sponsors.


Please give a monthly support here:
https://github.com/sponsors/SergeStinckwich

Regards,
--
Serge Stinckwic
h

Int. Research Unit
 on Modelling/Simulation of Complex Systems (UMMISCO)
Sorbonne University
 (SU)
French National Research Institute for Sustainable Development (IRD)
U
niversity of Yaoundé I, Cameroon
"Programs must be written for people to read, and only incidentally 
for machines to execute."

https://twitter.com/SergeStinckwich

[Pharo-users] More Morphic snags

[Markus Stumptner]

I have been trying to replicate the behaviour of an existing (non-Pharo, 
non-Smalltalk) application with Morphic. This provides grouping images 
in a workspace, and then switching between laying them out separately or 
"stacked" by double clicking on the group (or an image in it). When the 
group is stacked, it can be moved around as a single drag and drop 
operation. When the group is separated, dragging an image out of it 
removes it from the group.


On the surface this looked like a perfect fit to the submorph tree.  
Unfortunately, as both the Morphic chapter in Pharo by Example and the 
intro document by Maloney make clear, if you enable double clicking (by 
answering true to #handlesMouseDown:), you are interfering with what 
Maloney calls the "default behaviour" of being able to drag a Morph around.


How do I reinstate that behaviour if a group is clicked on and the 
double click does not happen? Neither document helps in explaining where 
that "default" can be found in the code.


Thanks
Markus

[Pharo-users] Morphic question

[Markus Stumptner]

Years ago, I asked a Morphic question here and in response was kindly 
provided with the code snippet at the bottom, which I puttered around 
with and it eventually led me to puttingsome useful functionality 
together, so thanks again.  I came across again now and as I played 
around with it, there is a question that I can't work out, silly as it 
may seem: in the example, the circle shows standard drag-and-drop 
behaviour, while the orange Morph "sticks" to the mouse once clicked and 
has to be clicked again to be dropped off.  I could not work out where 
(i.e., which method) that difference in behaviour comes from. It's not 
due to the order of processing; adding the CircleMorph second doesn't 
change things. Any ideas?


Notably, when I run the #exampleCircleMorph class method, the 
CircleMorph that opens on the screen does not show this behaviour, it 
"sticks" to the mouse in the same way as the orange Morph.


FWIW, this is Pharo 6 under Windows (7 or 10 makes no difference).


| window pane board background scaler|

background := AlphaImageMorph withForm: (ZnEasy getJpeg: 
'http://i.imgur.com/K1QR9vA.jpg').

background lock.

board := PasteUpMorph new.
board
color: Color gray;
borderWidth: 3;
borderColor: Color black;
extent: background extent;
backgroundMorph: background;
addMorph: (CircleMorph new color: Color cyan; position: 41@23; yourself);
addMorph: (Morph new color: Color orange; position: 1200@1200; yourself).

scaler := TransformMorph new.
scaler extent: background extent * 0.5.
scaler scale: 0.5@0.5.
scaler addMorph: board.

pane := ScrollPane new.
pane scroller addMorph: scaler.

window := pane openInWindow.
window position: 20@20; extent: 420@420.

Re: [Pharo-users] Pharo and instance variables ...

[Markus Stumptner]

It would break code all over the place...


On 18/10/2017 16:02, James Ladd wrote:

What if accessors were generated but not mutators?

Sent from my Commodore 64

On 18 Oct 2017, at 4:21 pm, Clément Bera > wrote:





On Wed, Oct 18, 2017 at 7:07 AM, James Ladd > wrote:


Hey David,

If you could only access instance variables in the class that
defined them and therefore only in a subclass via an accessor /
mutator method w that be a big problem in your view?


Yes.

I don't want to have to define accessors, which are public, just to 
have the subclasses access the instance variables.



Sent from my Commodore 64

On 18 Oct 2017, at 2:41 pm, David Mason > wrote:


In Pharo, open a browser on OrderedCollection, then click
"Variables" in the top left of the window and then "array"... if
you scroll through you can see that mostly OrderedCollection
methods use it, but some SortedCollection (a subclass) methods
also use it.

The model is similar to protected in Java (see
http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

) except there is no "Package" column.

On 17 October 2017 at 23:30, James Ladd > wrote:

Please could you provide an example?



On Wed, Oct 18, 2017 at 2:16 PM, David Mason
> wrote:

Any instance method in the class where the instance
variable is defined or in a subclass can access the
instance variable. Similarly for class methods to access
class-side variables, and for class and instance methods
to access class variables.

On 17 October 2017 at 23:04, James Ladd
> wrote:

Hello Pharo Users,

I'm wondering about instance variables for support
in Redline Smalltalk and
want to get my understanding straight.

Are instance variables only accessible (without
using #instVarNamed:) inside
the method with the same name as the instance variable?

eg:

   myInstVar
   ^ myInstVar.

Or can you reference an instance variable from a
method that doesn't have
the same name ?

   anotherMethod
   ^ myInstVar.

Can someone give me or point me to an example of
accessing an instance
variable in Pharo Smalltalk?

- James.




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









--
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Markus Stumptner]

Just to lead this back to the original question.  What you say is 
undoubtedly true.  It is not, however, necessarily something that a 
beginner will understand or be able to share in.  So, to a certain 
degree this may be a trap caused by having the excellent environment.  
The newbie who is not used to it and tries to get somehow organised 
before diving in will be scared off.


(I do realise that this is a matter of the time being available, but the 
fact remains that people coming from the outside may be held back this 
apparent lack of information, even though it is only a lack of 
information external to the image. It's the difference between the 
converted who are already going with the flow and those who want to dip 
a toe into the water.)


On 12/10/17 01:09, Offray Vladimir Luna Cárdenas wrote:


The more I use Pharo, the less I use web documentation. For me seems 
pretty suboptimal compared to live environment with code browser and 
GT-Spotter. Regarding the comment on Medium, it also took me little to 
find #raisedTo:, so the millage can vary. What I was missing was 
proper books for particular domains, but Pharo books are covering 
that. I don't know if a Q site could improve search-ability for 
newbies (certainly you can find little stuff in Stack Overflow).


My bet is about trying to create more "end user" tools (Grafoscopio is 
kind of this), besides tools for developers. There is a broad 
community of people who can be active contributors and members of the 
community, welcome Pharo and live coding a lot and don't complain that 
much about stuff that is not already pretty similar to what they 
already know (being that only English MOOC or online static html docs).


Cheers,

Offray


On 11/10/17 07:34, Dimitris Chloupis wrote:
for me it is a yes and no situation, yes its very coold to have your 
entire system in your fingertips but Pharo has serious issues with 
code organisation and I find the lack of namespaces quite 
inconvenient. You have to be careful how to name your classes which 
does not sound to me very OOP friendly.


Also the IDE does not handle spaggetification very well, sure you can 
find implementors , senders etc but if the execution chain is complex 
, welcome to spaggeti hell. But that is a problem with most other 
IDEs if not all as well. Problem is in this case that we have the 
very good rule of using sort methods which multiplies this problem 
and makes navigation even harder. Code becomes much easier to read 
per method and messages but much harder to understand in a bird eye view.


Some of that pain has been aleviated with the introduction of 
GTSpotter which I have praised quite a lot and I will continue to do 
so. But yeah there are more needed to be done in the department to 
make Pharo code navigation a more comfortable task.


On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz 
> wrote:


I dunno, maybe I’m weird, but I find the System Browser a
fantastic way to explore the class library. If you find a
class or method that isn’t well documented, write a comment
and send a change request. Stef told me this ages ago. I
might add, if you find a bug you should write a test that
exercises the bug and submit it on fogbugz (the bug tracking
system).


I will reference of response of mine to a similar opinion made by
Richard:

https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything-in-the-environment-c6bdd44f6eea

My 2 cents.




On Tue, Oct 10, 2017 at 11:59 PM, john pfersich
> wrote:


> On Oct 10, 2017, at 09:58, horrido
> wrote:
>
> Interestingly, I'm getting a fair amount of pushback on
this. Personally, I
> think it would be very helpful to have a live (updatable,
so as to keep it
> current) reference page for the class library, something
that developers can
> easily look up what they need. After all, most of the power
of Pharo comes
> from the class library and we need to make it as accessible
as possible to
> less experienced Pharoers (i.e., beginners).
>
> Exploring the class library through the System Browser is
very inefficient.
> This is further exacerbated by the fact that many classes
and methods are
> simply not well-documented (containing a cursory remark
which is just barely
> useful).
>
I dunno, maybe I’m weird, but I find the System Browser a
fantastic way to explore the class library. If you find a
class or method that isn’t well documented, write a comment
and send a change request. Stef told me this ages ago. I
might add, if you find a bug you should write a 

Re: [Pharo-users] Dark Mode

[Markus Stumptner]

On 28/08/17 06:07, Dimitris Chloupis wrote:



I completely agree - dark mode is great for content that you want to
look cool, but no one consumes. :-)


You assume wrong cause dark themes have been dominating GUIs for over 
3 decades now.
Not really; bright on dark was only dominant in the days of the CRT 
terminal when there were no "themes".  (Even if you could do it as a 
hardware switch, setting, say, a VT220 to black-on-white both looked 
terrible as it was more an uneven gray, and tended to dim  the tube more 
quickly by burning in the background.)


Instead, since full bitmap graphics happened, all screen interfaces back 
to Xerox's prototype office systems, then Lisa/Macintosh, and then 
Windows 2.1 have been using dark type on a white background for text 
work.  Partly this was because of the original office metaphor, but 
partly also because it was shown that it was easier (meaning, less error 
prone) to read.


Here's a study that showed that participants were 26% more accurate in 
reading text that way (note that "contrast reversal" on displays in 
those days meant dark characters on white background):


Bauer, D., & Cavonius, C., R. (1980). Improving the legibility of visual 
display units through contrast reversal.
In E. Grandjean, E. Vigliani (Eds.),  Ergonomic Aspects of Visual 
Display Terminals (pp. 137-142).

London: Taylor & Francis

There were other studies in the 1980s that didn't report lower errors 
but instead faster reading with black on white. Academically, the 
matter's pretty much considered settled - black on white is better for 
most of the population, and that's on screen, not on paper. (You can 
substitute any degree of light or creamy for the white, that's really a 
variation of screen quality.)


The engineering workstations of the late 80s and 90s (Sun etc) used 
black and white as the application default as well, with white on black 
limited to console/shell windows. This was partly for consistency with 
the old style, partly for easy contrast with application windows in a 
multi-window environment.


Pharo was the rare exception of using a white theme. Light themes may 
be popular but white are definitely not. The web is the last fort of 
bright themes, but the web was and still is eons behind when it comes 
to matters of UI.
Most other Smalltalks are dark-on-light by default all the way back to 
Smalltalk-80 out of Xerox PARC.  None of this had anything to do with 
the Web, which came after, but which obviously also profits from the 
same increase in readability.  Rather than behind, Smalltalk was ahead 
and the rest of the world followed.


The dark theme as default in Pharo I personally consider a step back. As 
someone who's been busy for 25+ years defending use of Smalltalk for 
real applications, a return to a primarily developer-cool presentation 
instead of a user-oriented default is IMO not a plus for a language 
branch that was billed as more industry-oriented (which IMO is not 
exactly the same as developer-oriented).  But I also understand the 
desire to attract developers with the look that's currently fashionable.


That said, I wonder if the recent preference for dark among developers 
(not Pharo-specific, but many languages) has to do with the rise of 
widespread code highlighting. I could see how colour highlighting shows 
up better on a dark background than being glared over by a white one.


Markus

Re: [Pharo-users] [Pharo-dev] TechTalk Dates for the rest of 2017

[Markus Stumptner]

I would. Beats Python...

On 22/08/17 02:08, Alexandre Bergel wrote:

Hi!

I am currently giving a lecture on Neural Networks and Genetic 
Algorithm/Programming.
Maybe I could turn this into an express 2 hours mini-lecture. Would this work?

Anyone is interesting in programming, from scratch, a small artificial 
intelligence?

Cheers,
Alexandre



On Aug 21, 2017, at 10:32 AM, Marcus Denker  wrote:

Hi,

We have added dates for tech talk discussions / Demos for the rest of 2017:
https://association.pharo.org/events

We need to find some topics. In the past we had often formal “talks” or demos 
about
a topic with discussion afterwards, but a more relaxed form of just an open 
discussion
about a topic is possible, too,

If you like to lead one of the dates (all but the November dates are available 
still), this
would be great.

If a date does find a topic, we keep it as an open discussion round.

Marcus

Re: [Pharo-users] System Browser "Implementors of..." drill down?

[Markus Stumptner]

I agree - the keyboard shortcuts will work for the initiated, but are 
not a replacement for the obvious menu entries that even experienced 
Smalltalkers from other versions will be missing in Pharo.


I think it is important to keep the entry barriers low in terms of not 
hiding useful functionality that people will be used to from other 
environments.


Markus

On 22/07/2016 16:54, Hernán Morales Durand wrote:
This was actually implemented in older versions of Pharo (or Squeak), 
the browser also included very handy buttons in the middle to save 
precious clicks.


The right thing to do is to replace the "..." non-sense with the 
selected method selector, and to offer another menu item which 
displays all method selectors of the currently selected method, and 
let the user to decide which one to browse.


Hernán

2016-07-21 14:54 GMT-03:00 Norbert Fortelny 
>:


Something I have not figured out how to do easily in the Pharo system
browser:
I am looking at a method and want to see how a message that is
used in this
method is implemented. In other Smalltalks (e.g. Cincoms) I use
the menu
item "Implementors of..." and get a list of all the messages that
are used
in this method and can choose one to drill down.
In Pharo I get an immediate answer but only the implementors of my
original
method.
Why are there those "..." at  the end of this menu item indicating
some
further choice when there is none?
How to do this drilling down in Pharo?




--
View this message in context:

http://forum.world.st/System-Browser-Implementors-of-drill-down-tp4907380.html
Sent from the Pharo Smalltalk Users mailing list archive at
Nabble.com.

Re: [Pharo-users] Pharo-users Question about the symbols

[Markus Stumptner]

As a result, internal names (e.g., method names) are usually symbols. 
Strings are normally used for string manipulation, symbols for 
unambiguous (but humanly readable!) internal reference (vulgo 'naming').


Markus


On 08/04/16 10:53, Ben Coman wrote:

A symbol is like a string, except that all symbols with the same value
are in fact the same object; that is, every #hello symbol is the exact
same object as every other #hello symbol.

See "identically equal" section here...
http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/08%20-%20Chapter%206%20-%20Special%20Symbol.pdf

cheers, ben

On Fri, Apr 8, 2016 at 7:20 AM, Valentin Ryckewaert
 wrote:

Hello everyone,

i'm learning Pharo and i'm having difficulties to understand the symbols,
what are they? How are they different of the ByteString ? Why are they
usefull ?
Why should I put #string where I can put 'string' ?

Thanks in advance for your answer.
Valentin Ryckewaert

Re: [Pharo-users] Beginner's question on morphs

[Markus Stumptner]

Thanks! Extremely useful answers.

Cheers
Markus

[Pharo-users] Beginner's question on morphs

[Markus Stumptner]

Hi, I'm trying to refamiliarize with Pharo again after a few years... 
trying to set up a simple game window  that uses a very large scrollable 
game board with a huge image as the background, so that game pieces 
placed on that background would scroll in and out of view. Any hints as 
how to best set that up in Morphic?


Thanks
Markus