How do you get the position and height of a pluggableOutliner?
How can you measure if an object is outside the screen?
The reason for this is that we are implementing a scrollbar to every self object.
Regards Helena
On Thursday 13 November 2003 13:43, helenameyer2000 wrote:
How do you get the position and height of a pluggableOutliner?
Well, I see a 'rawBox' slot in the pluggableOutliner which seems interesting, but the "raw" indicates that I shouldn't be using it directly.
Asking for "senders in family" gets me 'baseBounds', 'position' and 'position:'. So you might try
pOutliner position
and
pOutliner baseBounds height
where pOutliner is the object you are interested in.
How can you measure if an object is outside the screen?
This is very complicated since there might be any number of windows showing the same world. The object might be "outside the screen" for one window and yet right in the middle of another window.
If you don't care about this, then
| wc | wc: topmostOwner anyWindowCanvas. (wc offset ## wc size) intersects: baseBounds
seems to get the job done.
The reason for this is that we are implementing a scrollbar to every self object.
Scrollbars in general aren't very popular in Self. What would these do?
-- Jecel
--- In self-interest@yahoogroups.com, Jecel Assumpcao Jr <jecel@m...> wrote:
On Thursday 13 November 2003 13:43, helenameyer2000 wrote:
How do you get the position and height of a pluggableOutliner?
Well, I see a 'rawBox' slot in the pluggableOutliner which seems interesting, but the "raw" indicates that I shouldn't be using it directly.
Asking for "senders in family" gets me 'baseBounds', 'position' and 'position:'. So you might try
pOutliner positionand
pOutliner baseBounds heightwhere pOutliner is the object you are interested in.
We get the same position and the same height when we execute the above two lines in different objects.... How do we grab a specific object and ask for its height?
How can you measure if an object is outside the screen?
This is very complicated since there might be any number of windows showing the same world. The object might be "outside the screen" for one window and yet right in the middle of another window.
If you don't care about this, then
| wc | wc: topmostOwner anyWindowCanvas. (wc offset ## wc size) intersects: baseBounds
seems to get the job done.
But what are topmostOwner and anyWindowCanvas? We think that this should be implemented in pluggableOutliner prototype.
The reason for this is that we are implementing a scrollbar to every self object.
Scrollbars in general aren't very popular in Self. What would these do?
If an object is too big and outside the screen, it can be difficult to move around to see what's inside the object.
Regards, Helena
On Wednesday 19 November 2003 07:24, helenameyer2000 wrote:
We get the same position and the same height when we execute the above two lines in different objects.... How do we grab a specific object and ask for its height?
Just point to the object, click on the right mouse button (blue menu) and ask for "outliner for morph". Use the "E" button on the outliner to get the evaluator. In the evaluator, just type
position
and then the "get" button. Next type
baseBounds height
My example was meant to be used in some code rather than directly in the evaluator, where "self" is the object on which you opened the outliner. I wouldn't expect to get always the same answer doing it this way.
But what are topmostOwner and anyWindowCanvas?
Every morph has a 'owner', which is the morph into which it is embedded. This forms a chain until you get to an object that has nil as its owner. That should be a worldMorph. Just asking for 'topmostOwner' gives us directly the last element in the chain.
Why do we want that? That is the only object that knows anything about windows. But as I mentioned, that object may be in any number of windows. Asking for 'anyWindowCanvas' will return the drawing surface (so we can test borders) from one of them. As long as there is only one, that will be the right answer. If there is more than one window we should be smarter about choosing which one we are interested in.
We think that this should be implemented in pluggableOutliner prototype.
Sure.
Scrollbars in general aren't very popular in Self. What would these do?
If an object is too big and outside the screen, it can be difficult to move around to see what's inside the object.
I would prefer some convenient method for scrolling the whole world instead of something like this. For one presentation I did using Self, I modified the world morph to scroll when I typed the arrow keys. It is amazing how much more usable the whole user interface became! For example, it is hard to "carry" and object very far when you have to drop it to click on the radarView buttons all the time. The only problem is when some other morph has the typing focus.
-- Jecel
Hello
We want to change an objects slot (which is called "slider"), without changing the prototype of this obejct. Every time we change the value for slider in an object, the corresponding slider-slot in the prototype also get changed.. How do we avoid this?
Another issue:
In traits sliderMorph, in the method verticalMouseMove: evt, we want to change the position of the pluggableOutliner.
So far we have the following:
target position: ((target position x) @ (target position y - 75))
and target is set to pluggableOutliner.
But nothing happens..?
Thanks for the help so far !! Regards, Helena
On Tuesday 25 November 2003 12:56, helenameyer2000 wrote:
We want to change an objects slot (which is called "slider"), without changing the prototype of this obejct. Every time we change the value for slider in an object, the corresponding slider-slot in the prototype also get changed.. How do we avoid this?
Are you calling "prototype" the object from which you cloned or copied your new object (to which you are sending the 'slider:' message)? Or is it some parent of your new object?
Your problem shouldn't be happening in the first case, which is how we use these terms in Self. Other prototype based programming languages have a different notion of prototype.
(| parent* = traits clonable. slider <- 7 |) copy slider: 10
has no effect on the slider slot of the original (prototype) object, while
(| parent* = (| parent* = traits clonable. slider <- 7 |). localData <- 0 |) slider: 10
will change the parent (we don't call it prototype in Self) object, which will affect the child object as well.
In traits sliderMorph, in the method verticalMouseMove: evt, we want to change the position of the pluggableOutliner.
So far we have the following:
target position: ((target position x) @ (target position y - 75))
and target is set to pluggableOutliner.
But nothing happens..?
That looks about right and it is possible that it even worked but didn't see the results. Try adding the line
target changed.
after the one the moves the object.
-- Jecel
Hello again,
Our problem with inheritance is that when we make a new pluggableOutliner object, we want to add a sliderMorph to the object.
The slot target in the sliderMorph is set to the object pluggableOutliner, so our problem is that it is set to "pluggableOutliner" insted of "a pluggableOutliner"
Our implementation of method addSlider:
buildSliderTarget: pluggableOutliner Selector: 'scroll:' Color: color asEnhanchedColorForBackground: color
And implementation of buildSliderTarget: t ...
| f. s| s: sliderMorph copy colorAll: c. .. .. .. s target: t. t slider: s.
f: frameMorph copy color: c. .. .. .. f addMorphLast: s. body addMorphLast: f.
It is a general problem for us, that target is not set to "a pluggableOutliner" every where we need it. The code above is implemented in : "pluggableOutliner(a generalModel(...))"
(This is what we called the prototype)
Regarding the second issue:
We have tried to write "target changed", and now the object is redrawn in an other position, but the screen is not updated (you can still see the old version of the object...). How do we remove the old object?
/Helena
On Wednesday 26 November 2003 07:21, helenameyer2000 wrote:
The slot target in the sliderMorph is set to the object pluggableOutliner, so our problem is that it is set to "pluggableOutliner" insted of "a pluggableOutliner"
Our implementation of method addSlider:
buildSliderTarget: pluggableOutliner Selector: 'scroll:' Color: color asEnhanchedColorForBackground: color
And implementation of buildSliderTarget: t ...
The code I snipped away looks just fine, but shouldn't it be called from addSlider this way:
buildSliderTarget: self Selector: 'scroll:' Color: color asEnhanchedColorForBackground: color
?
In your version you are setting the target always to the same object (pluggableOutliner) independently of who is executing the code.
Regarding the second issue:
We have tried to write "target changed", and now the object is redrawn in an other position, but the screen is not updated (you can still see the old version of the object...). How do we remove the old object?
You have two choices: you can make the whole screen be redrawn (target owner changed) or you can send 'changed' to target twice (once before it is moved and again after it is moved).
I haven't tested either solution, but if both work I would expect the second one to be faster.
Nothing is redrawn automatically in Morphic (Self's graphic framework). When objects notice that they have changed, they add their bounds to a "damage region". Eventually, everything inside the damage region is redrawn and we start building a new damage region again for the next drawing cycle.
Adding the whole world to the damage region gets the job done, but will have a terrible performance.
Adding the original area of the morph (which now should show any previously covered morphs or the background) and the new area of the morph will redraw the fewest possible bits that still give your the correct image. It is easy to get things slightly wrong ("off by one" errors, for example) and have morphs leave a trail of "dirty pixels" as they move around on the screen.
Actually, there might be other choices beyond these two. I haven't looked very deeply into this issue.
-- Jecel
self-interest@lists.selflanguage.org
-
helenameyer2000 -
Jecel Assumpcao Jr