Hi,
Let me shortly introduce myself. I'm new in this Forum, but not at all with Smalltalk. I did a private Smalltalk project under IBM VisualAge Smalltalk 6.0 (see http://imarch.free.fr/), but at a HD crash 10 years ago I lost both VisualAge and the project, except for the documentation. Recently I decided to rebuild my former private project and I installed Squeak on my iMac. Essentially, main differences between the two are VisualAge's Widgets against Squeak's Morphs.
The Morph problem that I met: I create a Morph and from that I create another one and collapse the original one:
(morphA := )MorphA new morphA: (statements) morphB := MorphB new. self collapse.
When I close morphB, I want morphA to reopen, but I did not find any methods for that:
morphB: (statements) morphA “uncollapse …... how?” self currentWorld removeMorph: self.
I found a sort of “solution”, but is leaves a residu collapsed morph on the screen:
morphB: (statements) morphA currentWorld removeMorph: morphA. morphA openInWorld. self currentWorld removeMorph: self.
morphA reappears opened but the collapsed morphA is still visible on the display. “restore display (r)” does nothing, but clicking on any of the collapsed morph's actions x, v, + or – let it disappear.
Remarks: Update Squeak ends up in an error message. Monticello Browser can't get over 30 versions and ends up in an error message.
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
Hi and welcome to the Squeak world!
If you check the implementation of Morph>>collapse method, it is the following (in Squeak 4.5): collapse CollapsedMorph new beReplacementFor: self
The problem is the method returning self instead of returning the CollapsedMorph. You can either modify the method (discouraged), add your own method to the Morph class (remember to use the star prefix in the protocol name, and to use the proper name to assign it to a proper package), or just use the content of the method directly in your code.
My preferred way to do it would be adding a method to the Morph class. Let me assume the class category of my package is MyPackage. Just add the protocol *MyPackage with the method: myPackageCollapse ^ collapsedMorph new beReplacementFor: self.
Now you can do: |morph collapsedMorph| morph := Morph new. "collapse it" collapsedMorph := morph collapse. "uncollapse it" collapsedMorph collapseOrExpand.
Best wishes, Mateusz
Mateusz Grotek wrote
....... collapse CollapsedMorph new beReplacementFor: self ....... |morph collapsedMorph| morph := Morph new. "collapse it" collapsedMorph := morph collapse. "uncollapse it" collapsedMorph collapseOrExpand. .......
That will turn my morphA into a CollapsedMorph, where originally it is a subclass of a subclass of Morph, thus loosing morphA"s behaviour.
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
Dnia 14.08.2015 10:58:52, Fredrik Alink napisał(a):
Mateusz Grotek wrote
....... collapse CollapsedMorph new beReplacementFor: self ....... |morph collapsedMorph| morph := Morph new. "collapse it" collapsedMorph := morph collapse. "uncollapse it" collapsedMorph collapseOrExpand. .......
That will turn my morphA into a CollapsedMorph, where originally it is a subclass of a subclass of Morph, thus loosing morphA"s behaviour.
Your original morph is still referenced by the variable morph in the code above. collapsedMorph is a CollapsedMorph instance. You just need to keep it until you want to expand it. After expanding you throw it away.
| originalMorph collapsedMorph | originalMorph := yourMorph. "Your original morph is always here. It doesn't turn into a CollapsedMorph." ... ... ... collapsedMorph := morph collapse. "This is the CollapsedMorph. You need to keep it only until expanding." ... ... "You can still use your original Morph available in the variable originalMorph here." ... collapsedMorph collapseOrExpand. "Expanding it. Now you can ignore the collapsedMorph variable." ...
Mateusz Grotek wrote
Your original morph is still referenced by the variable morph in the code above. collapsedMorph is a CollapsedMorph instance. You just need to keep it until you want to expand it. After expanding you throw it away.
| originalMorph collapsedMorph | originalMorph := yourMorph. "Your original morph is always here. It doesn't turn into a CollapsedMorph." ... ... ... collapsedMorph := morph collapse. "This is the CollapsedMorph. You need to keep it only until expanding." ... ... "You can still use your original Morph available in the variable originalMorph here." ... collapsedMorph collapseOrExpand. "Expanding it. Now you can ignore the collapsedMorph variable." ...
I am trying to understand what you mean. Since I'm talking about 2 concurrent Morphs, I implemented your remarks like this:
MainConsole demoButtonClicked morph := ModelConsole new. self modelConsole: morph. "handshake" collapsedMorph := self myPackageCollapse. morph mainConsole: self. "handshake" morph collapsedConsole: collapsedMorph. "handshake"
ModelConsole xButtonClicked | collapsedMorph expandedMorph | "close all running Modelprocessors" " to be defined! " "close own Modelprocessor" self mainConsole isNil ifFalse: [ expandedMorph := self mainConsole. collapsedMorph := self collapsedConsole. "uncollapse MainConsole" collapsedMorph collapseOrExpand. "release handshakes" expandedMorph modelConsole: nil. self mainConsole: nil]. "Close ModelConsole" ^self currentWorld removeMorph: self
This really solves the problem, *except* for the following situation: Step 1: open the MainConsole Step 2: MainConsole > demoButtonClicked: the ModelConsole opens, the MainConsole collapses *Step 3*: click on the - sign of the collapsed MainConsole to uncollapse it *Step 4*: MainConsole > minimizeButtonClicked: to collapse it again Step 5: ModelConsole > xButtonClicked: the ModelConsole closes, the MainConsole opens, *but* an artefact of the collapsed MainConsole stays on the screen. ..... Step 6: click on the - sign of the artefact and it disappears ..... Step 7: MainConsole > exitButtonClicked: the MainConsole closes. ..... or: Step 6: MainConsole > exitButtonClicked: the MainConsole closes but the artefact stays *as active *MainConsole Step 7: click on the - sign of the collapsed MainConsole to uncollapse it Step 8: MainConsole > exitButtonClicked: the MainConsole closes.
Were: MainConsole > exitButtonClicked ^self currentWorld removeMorph: self
and: MainConsole > minimizeButtonClicked ^self collapse
So, much better but not perfect ......
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
I am trying to understand what you mean. Since I'm talking about 2 concurrent Morphs, I implemented your remarks like this:
MainConsole demoButtonClicked morph := ModelConsole new. self modelConsole: morph. "handshake" collapsedMorph := self myPackageCollapse. morph mainConsole: self. "handshake" morph collapsedConsole: collapsedMorph. "handshake"
ModelConsole xButtonClicked | collapsedMorph expandedMorph | "close all running Modelprocessors" " to be defined! " "close own Modelprocessor" self mainConsole isNil ifFalse: [ expandedMorph := self mainConsole. collapsedMorph := self collapsedConsole. "uncollapse MainConsole" collapsedMorph collapseOrExpand. "release handshakes" expandedMorph modelConsole: nil. self mainConsole: nil]. "Close ModelConsole" ^self currentWorld removeMorph: self
This really solves the problem, *except* for the following situation: Step 1: open the MainConsole Step 2: MainConsole > demoButtonClicked: the ModelConsole opens, the MainConsole collapses *Step 3*: click on the - sign of the collapsed MainConsole to uncollapse it *Step 4*: MainConsole > minimizeButtonClicked: to collapse it again Step 5: ModelConsole > xButtonClicked: the ModelConsole closes, the MainConsole opens, *but* an artefact of the collapsed MainConsole stays on the screen. ..... Step 6: click on the - sign of the artefact and it disappears ..... Step 7: MainConsole > exitButtonClicked: the MainConsole closes. ..... or: Step 6: MainConsole > exitButtonClicked: the MainConsole closes but the artefact stays *as active *MainConsole Step 7: click on the - sign of the collapsed MainConsole to uncollapse it Step 8: MainConsole > exitButtonClicked: the MainConsole closes.
Were: MainConsole > exitButtonClicked ^self currentWorld removeMorph: self
and: MainConsole > minimizeButtonClicked ^self collapse
So, much better but not perfect ......
Hi,
It's hard to tell what is wrong without interacting with your code. If you can put your code to SqueakSource3 then I or someone else might be able to help you. The only suggestion that comes to my mind by looking at the example above is that you can not only remove your console morph, but also the CollapsedMorph. Besides that, imho it's better to use the self delete, than to do things like self currentWorld removeMorph: self. In this way you can just do: morph delete. collapsedMorph delete. Nevertheless it's just a wild guess and I cannot tell anything without interacting with your app.
Best wishes, Mateusz
Mateusz Grotek wrote
It's hard to tell what is wrong without interacting with your code. If you can put your code to SqueakSource3 then I or someone else might be able to help you. The only suggestion that comes to my mind by looking at the example above is that you can not only remove your console morph, but also the CollapsedMorph. Besides that, imho it's better to use the self delete, than to do things like self currentWorld removeMorph: self. In this way you can just do: morph delete. collapsedMorph delete. Nevertheless it's just a wild guess and I cannot tell anything without interacting with your app.
Best wishes, Mateusz
I want to thank all for thinking about the problem with me. It was of much help. And 'morph delete' works fine.
Since the MainConsole is not a part of my model - I just created it to play with it for a better understanding of Morph (see my first message, Morph is new for me) - I won't put anymore efforts in it, so no automatic collapse.
As soon as my model runs, I'll put my code on SqueakSource3, but that might last a while ....., say months.
Regards, Fredrik
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
Dnia 13.08.2015 19:15:43, Fredrik Alink napisał(a):
Hi,
Let me shortly introduce myself. I'm new in this Forum, but not at all with Smalltalk. I did a private Smalltalk project under IBM VisualAge Smalltalk 6.0 (see http://imarch.free.fr/), but at a HD crash 10 years ago I lost both VisualAge and the project, except for the documentation. Recently I decided to rebuild my former private project and I installed Squeak on my iMac. Essentially, main differences between the two are VisualAge's Widgets against Squeak's Morphs.
Will your project be available on SqueakSource3?
Mateusz Grotek wrote
...... Will your project be available on SqueakSource3?
Tell me about SqueakSource3, where can I find it? As soon as it's running again, for sure I can make it available.
By the way, I have Squeak 4.4, should I go to 4.5?
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
Hi Fredrik,
Am 14.08.2015 um 12:02 schrieb Fredrik Alink:
By the way, I have Squeak 4.4, should I go to 4.5?
current Squeak is 5.0. 4.4 was delivered with the interpreter VM but can run on the faster Cog VM. It uses the old image format. It's the last Squeak where Project saving works. Squeak Projects are like several Desktops in Squeak. 4.5 is it's successor, still old image format. Just recently released: 4.6 is the current Squeak with the old image format and a quite different look. 5.0 comes with the even faster Spur VM which needs a new image format. Otherwise it's 4.6. This is where Squeak development will continue.
Whatever your choice, I assume it will make no difference re your collapsed Morph problem.
My personal advice is that you move to 5.0 unless you use Squeak projects for e.g. documentation and want to be able to transfer them to other images. In this case stick with 4.4.
If you move to 5.0 you may want to save your preferences in 4.4 (Tools in the main docking bar, preferences) and reload them in 5.0. Results are not perfect.
Cheers,
Herbert
Dnia 14.08.2015 11:02:14, Fredrik Alink napisał(a):
Mateusz Grotek wrote
...... Will your project be available on SqueakSource3?
Tell me about SqueakSource3, where can I find it? As soon as it's running again, for sure I can make it available.
By the way, I have Squeak 4.4, should I go to 4.5?
--
IMHO if there is nothing in your project which needs 4.4, you can move directly 5.0. To get it just go to http://squeak.org, click on the Download button, unzip, go to the unzipped directory and run either squeak.sh (on Linux), Squeak-5.0-All-in-One.app (on Mac) or squeak.bat (on Windows). That's all.
SqueakSource3 is a code repository (like github) for Monticello (an equivalent of git or svn). To use it go to: http://ss3.gemstone.com, click Register Member in the left panel and follow the instructions. After registering yourself you can register your project in the left panel. To use it in Squeak run Tools->Monticello browser. Click +Repository and fill the template (remember to change www.squeaksource.com to ss3.gemstone.com). After adding the repository you can add your package (+Package). The rules are simple: 1. All class categories which start with the name of a package belong to the package (e.g. Kernel-Chronology and Kernel-Exceptions class categories belong to the package Kernel). 2. Besides class categories you can add methods to classes from other packages. To make them belong to your package you have to prepend the protocol name with * (e.g. *System-Finalization protocol is a part of the System package, despite it being in the Object class). To see an example browse the class Object.
To read more about Monticello see e.g. section 6.3 of http://squeakbyexample.org/SBE.pdf . Some, probably a bit outdated documentation is also available here: http://www.wiresong.ca/monticello/v1/docs/ .
If you have any questions, I'll be glad to answer them. Mateusz
Mateusz Grotek wrote
IMHO if there is nothing in your project which needs 4.4, you can move directly 5.0. To get it just go to http://squeak.org, click on the Download button, unzip, go to the unzipped directory and run either squeak.sh (on Linux), Squeak-5.0-All-in-One.app (on Mac) or squeak.bat (on Windows). That's all.
.......
Yesterday I moved to the Squeak-5.0-All-in-One.app without any problems.
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
From: Fredrik Alink Sent: Thursday, August 13, 2015 2:16 PM To: beginners@lists.squeakfoundation.org Subject: [Newbies] How to reopen a collapsed Morph from another Morph?
Hi,
Let me shortly introduce myself. I'm new in this Forum, but not at all with Smalltalk. I did a private Smalltalk project under IBM VisualAge Smalltalk 6.0 (see http://imarch.free.fr/), but at a HD crash 10 years ago I lost both VisualAge and the project, except for the documentation. Recently I decided to rebuild my former private project and I installed Squeak on my iMac. Essentially, main differences between the two are VisualAge's Widgets against Squeak's Morphs.
The Morph problem that I met: I create a Morph and from that I create another one and collapse the original one:
(morphA := )MorphA new morphA: (statements) morphB := MorphB new. self collapse.
When I close morphB, I want morphA to reopen, but I did not find any methods for that:
morphB: (statements) morphA “uncollapse …... how?” self currentWorld removeMorph: self.
See implementors of >> collapseOrExpand on a workspace type in collapseOrExpand and press Alt-b.
All the best,
Ron Teitelbaum
I found a sort of “solution”, but is leaves a residu collapsed morph on the screen:
morphB: (statements) morphA currentWorld removeMorph: morphA. morphA openInWorld. self currentWorld removeMorph: self.
morphA reappears opened but the collapsed morphA is still visible on the display. “restore display (r)” does nothing, but clicking on any of the collapsed morph's actions x, v, + or – let it disappear.
Remarks: Update Squeak ends up in an error message. Monticello Browser can't get over 30 versions and ends up in an error message.
-- View this message in context: http://forum.world.st/How-to-reopen-a- collapsed-Morph-from-another-Morph-tp4842627.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Ron Teitelbaum wrote
..... See implementors of >> collapseOrExpand on a workspace type in collapseOrExpand and press Alt-b. .....
Sorry,I didn't get a reasonable clue out of that. The thing is when I click a button *inside of* the morph, it vanishes. But when I address the same selector from the outside, the residue stays on the screen.
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
From: Fredrik Alink Sent: Friday, August 14, 2015 3:22 PM
Ron Teitelbaum wrote
..... See implementors of >> collapseOrExpand on a workspace type in collapseOrExpand and press Alt-b. .....
Sorry,I didn't get a reasonable clue out of that. The thing is when I
click a
button *inside of* the morph, it vanishes. But when I address the same selector from the outside, the residue stays on the screen.
Didn't get that from your email sorry. Have a look at Morph>>changed. Calling changed on the container should redraw the morph to remove the residue.
All the best,
Ron Teitelbaum
-- View this message in context: http://forum.world.st/How-to-reopen-a- collapsed-Morph-from-another-Morph-tp4842627p4842922.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Ron Teitelbaum wrote
..... Didn't get that from your email sorry. Have a look at Morph>>changed. Calling changed on the container should redraw the morph to remove the residue. .....
No change, still having the residue. Sorry.
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
Hi Fredrik,
Could you post more details like example code that shows the error, and maybe a picture of what you are seeing?
Ron
-----Original Message----- From: beginners-bounces@lists.squeakfoundation.org [mailto:beginners- bounces@lists.squeakfoundation.org] On Behalf Of Fredrik Alink Sent: Friday, August 14, 2015 4:59 PM To: beginners@lists.squeakfoundation.org Subject: [Newbies] RE: How to reopen a collapsed Morph from another Morph?
Ron Teitelbaum wrote
..... Didn't get that from your email sorry. Have a look at Morph>>changed. Calling changed on the container should redraw the morph to remove the residue. .....
No change, still having the residue. Sorry.
-- View this message in context: http://forum.world.st/How-to-reopen-a- collapsed-Morph-from-another-Morph-tp4842627p4842944.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Ron Teitelbaum wrote
Could you post more details like example code that shows the error, and maybe a picture of what you are seeing?
http://forum.world.st/file/n4843032/SQ.png
Code:
*Class hierarchy:*
Morph BaseInterface MainConsole ModelConsole
*step 1:*
MainConsole new super initialize ( <initialisations> self initScreenItemStates. self openWindow. self openInWorld. owner := self currentWorld)
The MainConsole shows up.
*Step 2:*
(MainConsole) demoButtonClicked self modelConsole: ((ModelConsole new) “init as in MainConsole” mainConsole: self; yourself); collapse.
The ModelConsole shows up, the MainConsole collapses.
*Step 3:*
(ModelConsole) xButtonClicked "close own Modelprocessor" self mainConsole isNil ifFalse: [ "uncollapse MainConsole: remove and then reactivate" self mainConsole currentWorld removeMorph: (self mainConsole). self mainConsole openInWorld." "disconnect MainConsole" self mainConsole modelConsole: nil. self mainConsole: nil]. "close ModelConsole" ^self currentWorld removeMorph: self
The MainConsole shows up, the ModelConsole disppears, but the collapsed MainConsole stays visible on screen.
*Step 4:*
(MainConsole) exitButtonClicked self modelConsole isNil ifFalse: [self modelConsole exitButtonClickedInMainConsole]. ^self currentWorld removeMorph: self
The MainConsole disappears, but the collapsed MainConsole stays visible on screen. Deopending of the order you do the abov, it is still 1 time active, otherwise it is dead. When deaad, it just disappears from the screen when clicking on x, v, + or –.
-- View this message in context: http://forum.world.st/How-to-reopen-a-collapsed-Morph-from-another-Morph-tp4... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
From: Fredrik Alink Sent: Saturday, August 15, 2015 6:22 AM
Ron Teitelbaum wrote
Could you post more details like example code that shows the error, and maybe a picture of what you are seeing?
[Ron Teitelbaum] Thanks that is much more clear.
Try replacing collapse with collapseOrExpand.
Then
self mainConsole currentWorld removeMorph: (self mainConsole). self mainConsole openInWorld.
With self mainConsole collapseOrExpand.
I think the issue here is that the console changed from a SystemWindow to a CollapsedMorph. To close the CollapsedMorph you need to call getCollapsedFrame and close that. collapseOrExpand toggles the state between collapsed and expanded and takes care of that for you.
All the best,
Ron
Code:
*Class hierarchy:*
Morph BaseInterface MainConsole ModelConsole
*step 1:*
MainConsole new super initialize ( <initialisations> self initScreenItemStates. self openWindow. self openInWorld. owner := self currentWorld)
The MainConsole shows up.
*Step 2:*
(MainConsole) demoButtonClicked self modelConsole: ((ModelConsole new) “init as in MainConsole” mainConsole: self; yourself); collapse.
The ModelConsole shows up, the MainConsole collapses.
*Step 3:*
(ModelConsole) xButtonClicked "close own Modelprocessor" self mainConsole isNil ifFalse: [ "uncollapse MainConsole: remove and then reactivate" self mainConsole currentWorld removeMorph: (self mainConsole). self mainConsole openInWorld." "disconnect MainConsole" self mainConsole modelConsole: nil. self mainConsole: nil]. "close ModelConsole" ^self currentWorld removeMorph: self
The MainConsole shows up, the ModelConsole disppears, but the collapsed MainConsole stays visible on screen.
*Step 4:*
(MainConsole) exitButtonClicked self modelConsole isNil ifFalse: [self modelConsole exitButtonClickedInMainConsole]. ^self currentWorld removeMorph: self
The MainConsole disappears, but the collapsed MainConsole stays visible on screen. Deopending of the order you do the abov, it is still 1 time active, otherwise it is dead. When deaad, it just disappears from the screen when clicking on x, v, + or –.
-- View this message in context: http://forum.world.st/How-to-reopen-a- collapsed-Morph-from-another-Morph-tp4842627p4843032.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Fredrik Alink -
Herbert König -
Mateusz Grotek -
Ron Teitelbaum