Dan, i've built a subclass of ScrollPane called PluggableScrollMorph that takes any ol' morph to be displayed inside the scroll region. in doing this, however, i've run across a snag. i've described the problem below. i have also attached the changes i have made to ScrollPane. if i am on the wrong track, the please set me to rights. if not, i'd like to submit my changes to be included in the next set of updates.
when i first starting playing around with ScrollPane morphs, i thought that adding a morph to the scrollable region would be as simple as something like:
ScrollPane new addMorph: (EllipseMorph new extent: 50@300); openInWorld
while playing around with Morphic and trying to get familiar with everything i discovered that i could do the same thing interactively in a Morphic Project by:
World->new morph...->Basic->EllipseMorph EllipseMorph->resize World->new morphs...->Windows->ScrollPane drag EllipseMorhp on top of ScrollPane EllipseMorph->embed... ScrollPane
both of these give me the same thing: a result other than the one i was hoping for--the EllipseMorph sits on top of the scroll pane, not inside the scroll region.
when building the ScollPane interactively, i noticed that when i went to embed the EllipseMorph inside the ScollPane i could choose to embed it inside some unnamed TransformMorph and i was closer to the result i wanted. rummaging through source code in the image i found that the programmatic equivalent was to ask the ScollPane for its scroller and put the EllipseMorph there.
| pane | pane := ScrollPane new. pane scroller addMorph: (EllipseMorph new extent: 50@300). pane openInWorld
well, there was two problems with this. number one, i didn't like it. it seemed like a violation of encapsulation to know that you needed to ask for scroller to add your morph to. number two, when you add your morph to the scroller, the ScrollPane doesn't know to update itself, so the scollbar doesn't adjust itself.
so, i "fixed" both of these problems by rewriting addMorph: in ScrollPane to add new morphs to the scroller and then update itself. (i also had to make changes to initialize.)
and it was Good.
until, in the course of building PluggableScrollMorph i realized that maybe it wasn't as easy as that. now that the submorphs are all inside the scroller, i see that i'll need to rewrite quite a few methods that get inherited. the first one i came across was replaceSubmorph:by:, but it looks like there are quite a few more. in addition, there are quite a few methods (200+) in the Morph heirarchy that reference the submorphs instance variable directly; these should probably get the collection of submorphs by calling an accessor method that can be overridden for container objects like ScrollPane.
so, i'm not quite sure if i am on the right track. let me know what you think.
david
At 09:44 PM 6/21/99 -0700, you wrote:
Folks -
You may have noticed Squeak Central laying low through the last couple of
mail storms. It's not that we're not interested, it's just that we have been busy.
We have made some progress in integrating balloon with morphic, integrating
3D with morphic, and integrating normal programming with scripting and viewers. Also a unification of WorldMorphs with PasteUpMorphs so that any world or pasteUp can be written out to a SqueakPage, and then read in as a world, a pasteUp, or the page of a book. Also some steps toward better modularity, such as being able to atomically assert/revert changes when entering/leaving a project. And some fun new stuff in music that lets you enter melodies from a keyboard into a score, and then copy and paste them and play the results, as well as some tweaks that make it easier to play with looped sampled sounds.
It's my hope to assemble all of this into a new image some time next week,
but it might take a bit longer as several of the changes touch a lot of code. We have lots of updates to put out, and I will probably release a spate of them toward the end of the week.
A number of interesting enhancements and bug fixes have been put forward
from this mailing list. Please let me know privately of anything you feel deserves special consideration for inclusion in the main line release.
In case you wonder, everyone here resonates with the desire to spruce up
Squeak.org, and to clarify our mission a bit in the process, but we probably won't take any real action until we have put out the next release.
Walk tall and talk Small
- Dan
Attachment converted: Anon:ScrollPane.26Jun536pm.cs (TEXT/MSIE) (0000AD11)
-- j. david farber oo architect+mentor numenor labs incorporated in sunny boulder colorado dfarber@numenor.com www.numenor.com
Since no one responded to this (unless you got some private email), I thought I'd throw in a few thoughts. I don't have any clear cut answers, though.
I don't know if it's possible to fool Morphic into thinking that a ScrollPane's submorphs are only the things inside the scroller. What about the ScrollBar morph? It's still a submorph of ScrollPane which needs to be drawn, etc, but it's definitely not inside the scroller.
The submorphs/owner concept in Morphic seems a little different than the contents/container concept in the VisualWorks ScrollWrapper. In Morphic, everything that's drawn needs to be a submorph, whereas in VW the "contents" are more specific, such as the stuff inside a scroll region.
I guess one answer is to somehow merge the ScrollBar class into ScrollPane, so that the ScrollBar is no longer a submorph? Or maybe make your own new merged class, but leave the old ScrollPane alone? (Hmm, would the Transform functionality need to be merged too?)
Or maybe you could continue on as you are, overriding the problem methods which have references to the submorphs instvar.
In any case, a working PluggableScrollMorph widget which you could plop any morph into would be *extremely* useful, definitely worthy of inclusion in the base image. So don't give up yet. :-)
- Doug Way EAI/Transom Technogies, Ann Arbor, MI dway@eai.com, dway@mat.net http://www.transom.com
On Sat, 26 Jun 1999, David Farber wrote:
Dan, i've built a subclass of ScrollPane called PluggableScrollMorph that takes any ol' morph to be displayed inside the scroll region. in doing this, however, i've run across a snag. i've described the problem below. i have also attached the changes i have made to ScrollPane. if i am on the wrong track, the please set me to rights. if not, i'd like to submit my changes to be included in the next set of updates.
when i first starting playing around with ScrollPane morphs, i thought that adding a morph to the scrollable region would be as simple as something like:
ScrollPane new addMorph: (EllipseMorph new extent: 50@300); openInWorld
while playing around with Morphic and trying to get familiar with everything i discovered that i could do the same thing interactively in a Morphic Project by:
World->new morph...->Basic->EllipseMorph EllipseMorph->resize World->new morphs...->Windows->ScrollPane drag EllipseMorhp on top of ScrollPane EllipseMorph->embed... ScrollPane
both of these give me the same thing: a result other than the one i was hoping for--the EllipseMorph sits on top of the scroll pane, not inside the scroll region.
when building the ScollPane interactively, i noticed that when i went to embed the EllipseMorph inside the ScollPane i could choose to embed it inside some unnamed TransformMorph and i was closer to the result i wanted. rummaging through source code in the image i found that the programmatic equivalent was to ask the ScollPane for its scroller and put the EllipseMorph there.
| pane | pane := ScrollPane new. pane scroller addMorph: (EllipseMorph new extent: 50@300). pane openInWorld
well, there was two problems with this. number one, i didn't like it. it seemed like a violation of encapsulation to know that you needed to ask for scroller to add your morph to. number two, when you add your morph to the scroller, the ScrollPane doesn't know to update itself, so the scollbar doesn't adjust itself.
so, i "fixed" both of these problems by rewriting addMorph: in ScrollPane to add new morphs to the scroller and then update itself. (i also had to make changes to initialize.)
and it was Good.
until, in the course of building PluggableScrollMorph i realized that maybe it wasn't as easy as that. now that the submorphs are all inside the scroller, i see that i'll need to rewrite quite a few methods that get inherited. the first one i came across was replaceSubmorph:by:, but it looks like there are quite a few more. in addition, there are quite a few methods (200+) in the Morph heirarchy that reference the submorphs instance variable directly; these should probably get the collection of submorphs by calling an accessor method that can be overridden for container objects like ScrollPane.
so, i'm not quite sure if i am on the right track. let me know what you think.
david
At 09:44 PM 6/21/99 -0700, you wrote:
Folks -
You may have noticed Squeak Central laying low through the last couple of
mail storms. It's not that we're not interested, it's just that we have been busy.
We have made some progress in integrating balloon with morphic, integrating
3D with morphic, and integrating normal programming with scripting and viewers. Also a unification of WorldMorphs with PasteUpMorphs so that any world or pasteUp can be written out to a SqueakPage, and then read in as a world, a pasteUp, or the page of a book. Also some steps toward better modularity, such as being able to atomically assert/revert changes when entering/leaving a project. And some fun new stuff in music that lets you enter melodies from a keyboard into a score, and then copy and paste them and play the results, as well as some tweaks that make it easier to play with looped sampled sounds.
It's my hope to assemble all of this into a new image some time next week,
but it might take a bit longer as several of the changes touch a lot of code. We have lots of updates to put out, and I will probably release a spate of them toward the end of the week.
A number of interesting enhancements and bug fixes have been put forward
from this mailing list. Please let me know privately of anything you feel deserves special consideration for inclusion in the main line release.
In case you wonder, everyone here resonates with the desire to spruce up
Squeak.org, and to clarify our mission a bit in the process, but we probably won't take any real action until we have put out the next release.
Walk tall and talk Small
- Dan
Dan, i've built a subclass of ScrollPane called PluggableScrollMorph that takes
...much snipped...<
so, i'm not quite sure if i am on the right track. let me know what you think.
david
David -
I agree that this is a component that we need (I hope to provide a mechanism by which any morphic world can be read from a web page and viewed in such a window). Without time to address all your questions right now, I will take a crack at fixing your code or doing one myself. Also, I just noticed that Bob Arning has done essentially this in his FMP game (TwoWayScrollPane), so I might build on that (and you might want to look at it yourself -- Bob's pretty handy with Squeak ;-).
- Dan
Just wondering if any other Squeakers were going to be at SIGGRAPH 99 next month in Los Angeles.
If so, maybe a few of us could get together informally at some point... I'll be there with a laptop with Squeak and Whisker running, anyway.
- Doug Way EAI/Transom Technogies, Ann Arbor, MI dway@eai.com, dway@mat.net http://www.transom.com
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
David Farber -
Doug Way