[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Feedback on Self 4.0
>
>
> Attached is a list of questions and problems I found when using Self 4.0.
Thanks Kieth ... here are a few quick comments...
First of all thanks very very much for the neat and thoughful feedback.
We really appreciate your work. My remarks below, indented with ** symbols.
--Randy
===============================================
Well, I've had a little time to play around with Self 4.0, and I've come up
with a list of bugs, suggestions, and questions.
NOTE: Some of this refers to a "pupil", a morph that I created as my first
programming example. It implements a Self version of "xeyes". It is
designed to be used by having a circle as its owner, and it follows the
handMorph, but stays within the bounds of its owner. It is started up
via a popup menu on the 2nd mouse button. It is working now, and it
could be an interesting morph to include in a demo system (or as an
exercise for a geometry class :). I'd like to provide you my pupil
morph, however one of the problems I ran into below (#16) is not allowing
me to save my module!!!
1. Is there a way to Cut/Copy/Paste text between Self World and standard X
applications (i.e. use the standard X clipboard)?
** Sorry about this, but as I recall now, we found such facilities to
** be unrelieable. I can't recall the exact problems.
2. When (and to whom) do I need to use changed? In my pupil example, I
changed the position of a morph within its parent. Sending 'changed' to
the morph caused it to be redrawn in its new position, however its old
position in its owner morph still showed it there. I had to do a 'owner
changed' to get this to work correctly. Should this be necessary?
** Send changed first, before setting the position, to indicate that the
** curent screen area for the object will need to be updated. Then move
** the object and send changed again, so that the new area on the screen
** will be updated. Get it? You should NOT have to send changed to the owner,
** though this would obviously work.
3. Dismissing an Object that has arrow pointing to it, the arrow does not
automatically detract.
** I can't reproduce this, but arrows were a last minute thing, so I believe
** there are bugs in there.
4. Adding a Pop-up UIMenu2 off of the pupil on Mouse Button 2, I choose "Start"
to make the pupil active. This works correctly, however, when I do another
Mouse Button 2 press over the pupil, when the Menu comes up, it does not
highlight the option underneath the handMorph. Also, clicking on an option
does not do anything. I have to click on the option a 2nd time for it to
work.
** I woner if this is related to your sending changed to the owner at each
** mouse move? Anyway, I don't recognize it as a common behavior.
5. Grabbing the arrow of a slot and dropping it on a UIMenu2 properly
associates the 2 objects, however the button on the right hand of the slot
disappears.
** I'm not sure I get this, but the arrow stuff is kind of complicated.
** The head of the arrow IS the button! Only -- ahem -- it behaves
** differently once sprouted. This is a feature! This is a feature!
** When sprouted, the thing acts like a regular carryable thing, but when
** you drop it back in place at the right end of the slot,
** it acts like a button again.
6. Since some morphs are big (vertically and/or horizontally), it would be nice
to have actions to move outliner with regard to the current canvas view (or
vice versa) so that the next "page" or the "edge" (up, down, left, or right)
is visible. This would be particularly useful for expanded outliners of
objects. Of course, the paging with regard to moving the canvas can already
be done with the radar morph.
** True. If only thee were 8,978 hours in a day...
7. Where's the trashCanMorph?
** Guess you have to say trashCanMorph copy.
8. Could speed up vector and sequence inserts/removals by providing a traits
vector method equivalent to memmove(), instead of looping one-by-one and
moving one element at a time.
9. Generally, I'd like to see more basic methods added to some of the basic
core traits and prototypes, so that everyone doesn't have to reinvent the
wheel. For example, I created a "distanceTo:" method for points, and a
"isIn:At:" method for morphs.
** Lots of enhancements could be imagined. I hope there is some
** comfort at least in your ability to do it. We had to stop somewhere...
10. Add parenthesis matching to Text Edits.
** That would be cool!
11. How do I change the handMorph's appearance? Changing vectorOffsets of my
handMorph does not change cursor. Then I tried using the handMorph
outliner's menu option "Show Morph", which hung the entire UI environment.
** Yes, that's a problem.. I've fixed this in our in-house version. It was not easy
** because all the event dispatching stuff was weirdly
** overloaded to give different event handling semantics for hands.
** So you hang, or get very strange event behavior for hand morphs when not
** used in the normal way. In my system here it is all better now. Make
** new hands, pick them up, change their color, and even "put them on" like
** a glove (press meta-escape to shed your current hand, shift-meta-escape
** to "pick a hand up and put it on".)
12. Attempting to "Show Morph" for many prototype morphs either hangs UI or
crashes World.
** Some of our prototypes are not fully functional without proper initialization.
** This may not be just lazy coding on our part..there are some deep issues esp
** ecially around text size hen text is not yet in any world.
13. Create a horizontal line, grab it and move the mouse around. Traces of the
line remain in the window. If another window is placed on top and then
removed, the traces disappear. Somehow the UI seems to get confused about
how thick the line is, or something like that.
14. Dragging something where mouse pointer goes out of window, releasing mouse
button, but the object being dragged still thinks that it is being dragged.
** Yes, these are bugs, thanks..
15. I hold down a mouse button over an object to choose a pop-up menu, but
decide to do something else, so I release the mouse button. Later on, the
menu appears, and when the UI processes my mouse release, it does so as if
the menu was showing at the time I released the mouse button. This causes
an unwanted action to occur. The UI should process such an event based
upon the status of the canvas at the time of which the button release
occurred. I believe that this is a general problem with the UI and
that it probably extends to other situations where the event processing
falls behind the actual events.
** I thought we had this working at one point. Sigh.
16. Trying to save the new module I created for the pupil morph, I get the
following error message:
primitiveFailedError: the '_AsObject' primitive failed.
Its receiver was 4.
Looking at the stack frame, it only shows 1 frame:
4 _AsObject
** I am not sure how this happened, perhaps yu have to tell the
**slot to be a "follow slot" kind of slot, see the "show annotation"
** middle button menu on the slot.
17. Very often, the entire UI gets hung up. I suspect that many times (if not
all) it is caused by my own improper messing around, however there is no
way to tell what happened or why. When this happens, pressing Ctrl-C at
"Self" prompt, I get the following:
----------------Interrupt-----------------
Ready:
<0> ready process: perProcessGlobals prompt mainInputLoop
<1> scheduling process: UI2 stepProcess
Sleeping:
<2> sleeping process: UI2 step timeout process
------------------------------------------
Select a process (or q to quit scheduler):
** Not sure what to say here...yes, you can shoot yourself in the foot
** quite easily. One trick may be to start a separate world
** for experimentation, it can contain weird morphs that you keep
** out of the main world.
18. For some reason, when a pupil is subscribed to cursor events, the
carpet morph no longer works correctly. The carpet morph appears to
the right and down from where it should.
** !!? Got me there...
19. When typing the following into an object slot:
mouseMove: evt = ()
I got an error saying that the object could not be empty for a method with
args. This is not necessarily an error. I needed to do precisely the
above to solve the problem I had in #7 above. I ended up getting around
this by changing it to the following:
mouseMove: evt = ( self )
** well, that is what you are supposed to do. () Does not mean an empty method,
** it is (for some odd reason) an empty object. If () were a method, what would
** it return? See the problem?
20. How come the filingOut/protype category/slot is on the morph prototypes,
and not on the traits morph?
** This is just a piece of policy used by the transporter. The
** slot has to be in the very object itself. Weird, eh? I think
** this is part of a very deep issue, actually, but I am too tired to
** go after it here...
21. Since mouse movement events are done by subscription, how does a morph
track movement events only when the mouse is on top of it? Must this morph
constantly track the mouse and constantly check whether the mouse is
actually currently on top of it?
** I think that is the case.
22. I found some problems with the animation. I created a gasTank using the
Shell command "gasTank copy". I added atoms to it, and targeted Start/Stop
buttons, which I embedded in the gasTank morph. I moved it into its own
window. Upon starting it, I found 3 problems:
a. Sometimes, attempting to drag the gasTank back to the 1st window
would fail. It would "get stuck" in the 2nd window.
** Yow! Haven't seen this, but fdon't do to much dragging...
b. When I successfully dragged the gasTank back to the 1st window, I
found that the buttons did not work correctly. Pressing the "Stop"
button appeared to do nothing. Pressing the "Start" button appeared
to speed up the motion of the atoms!
** I think I get why...maybe this is a bug the world-to-world transfer code. When
** we move stuff between windows, we should have it stop getting stepped by
** the first world, and start getting stepped by the second. Your gas tank,
** though in world 1, was being driven by a step message from world 2.
** Stop would do nothing, start would add an additional driving force due to
** the additional step meessage eminating from world 1!
c. After a short time, I got an error dialog in the 2nd window saying:
"The world crashed while stepping activity:
a morphStepActivity(a gasTank (type: gasTank))"
and I also got a Debugger object, which said:
"Process: 'UI2 stepProcess'
Lookup errorl, 'origin' not found."
After this, the gasTank buttons worked correctly again!!!
** This is kind of consonant with my above guess, though I can't explain
** the origin not found thing.