Squeak-dev October 1999

squeak-dev@lists.squeakfoundation.org

141 participants
396 discussions

RE: red/yellow/blue buttons an anachronism?
by Michael Klein 04 Oct '99

04 Oct '99

On Monday, October 04, 1999 8:52 AM, Peter Crowther [SMTP:Peter.Crowther@IT-IQ.com] wrote: > > From: Michael Klein [SMTP:Mklein@nts.net] > > Peter Crowther wrote: > >>> The names of the buttons should be semantic, not color or positional. > > > >> ... unless the semantics vary between different parts of the same system, > in > >> which case no single semantic naming convention can suffice. > > > Exactly. No single naming scheme an suffice. > > Er... that's not *quite* what I said --- see above. Close enough. Of course at some point, even #selectAt: or #operationMenuButtonPressed (made up selectors) get translated into more context-specific message. > > The names should be chosen > > appropriate to the module within which they reside. > > This gives the problem of a user of multiple environments having to remember > the physical-to-gesture mapping for each environment Yes. And that problem should be solved by the computer... Not the user. I.E. network transparency. My preferences travel around with me. If that takes an entire Image, or worse yet, and entire computer.... well, always an issue. I happen to use an alternate input device called a Twiddler http://www.handyKey.com And, If I want this "configuration", I have to take it with me. > --- and the complexity > increases for the environment having to remind the user. Help messages > change from 'click the yellow mouse button' to 'perform your gesture X if > you are in MVC; perform your gesture Y if you are in Morphic; perform your > gesture Z if it's a full moon and high tide'. Help messages should be bound to the preferences, then. Remember the lesson of MVC, separation of concerns. I think it is great that the same application in Squeak can have a UI's developed in two different frameworks.... Maybe, some day, that will help in developing vendor-neutral Smalltalk UI's > Hard to code, without careful > consideration of the gesture interface and how the user help system can lift > information out of the gesture mappings. Yep. > > If you are doing a UI framework, like MVC or Morphic, > > Then I would hope you would have some coherent semantics for your > > input scheme. > > I agree, but... *within* each of MVC or Morphic (awkward when you flick > between environments), or try to facilitate agreement *between* MVC and > Morphic. Agreed. But also facilitate agreement between Dolphin, and VW, and VA, and ... > I used to have three computer systems on my desk: Mac, Windows NT and > SunVIEW/SunOS. Any coherent semantics goes out of the window at system > boundaries. A Mac may be easy to use for experienced (or even novice) Mac > users, but becomes hell when you interleave use of two other incompatible > systems for about the same time. I needed coherence across these multiple > interfaces. I have the same situation (except only the SparcStation is on the desk... the rest are underneath. I use Smalltalk to achieve transparency. The three button mouse on all three machines works the same. I no longer use 3 keyboards and three mice. Now I just use VNC (it's great) > > (How fun would that be... towing > > windows around your screen :-? ) > > Would the undo button need a sound sample with a loud beep and 'Warning... > user reversing'? :-) Would we use the rules of the road to solve resource locking problems :-? > > The right thing to do is to decide on the semantics you want, and then > > figure out good UI gestures to invoke them. > > Yes, but the original discussion was about documentation of those gestures > across multiple environments rather than the gestures themselves within a > single environment. Again, a seemingly simple question on the squeak-list provoking deep thought. This thread has surface before. One Smalltalk replied that he used fingernail polish to make his mouse buttone the "correct" color. > > How hard > > would the piano be to play if all of the keys were laid out in a single > > row, > > rather than with the white-black scale-revealing system we use today? > > I'd prefer it. I know several (sloppy) keyboard players who just ignore the > front half of a keyboard and use those nice evenly-spaced keys at the back > --- especially those who work with singers who regularly want stuff dropped > a semitone on gigs because their voice feels rough! As you say elsewhere, > the UI has most variation. Even the evenly spaced back of the keyboard has the chromatic scale represented by look (color) and feel (height). I think this helps in playing. "fretless" instruments (like the trombone and violing) "scare" me.... Im just a novice player, though. > > Better still, provide an easy mechanism for users to customize and > > extend their own mappings. > > Easy and *consistent*. It's this consistency that is hard to achieve across > environments, but is what many users want --- witness fvwm95 on Linux, for > example, for those MicroWeenies who can't let go of their Win95 interface. My problem is I want olvwm (although Id settle for fvwm) on Windows. Again, the easiest solution is VNC > I was impressed with VisualWorks when it first came out; the idea of > emulating the platform's look-and-feel was (and still is) neat. But Squeak > has (two incompatible) cross-platform looks-and-feels; is this better (for > cross-platform users), worse (for single-platform users), or just different? > I don't know. And you can develop your own look and feel, which is great... in VW. Again, Morphic and MVC are more than look and feel differences. I think they are framework differences, similar to when VW added events to its MVC, but squeak's morphic is a much more major variation in framework. -- Mike

1 0

RE: red/yellow/blue buttons an anachronism?
by Peter Crowther 04 Oct '99

04 Oct '99

> From: Michael Klein [SMTP:Mklein@nts.net] > Peter Crowther wrote: >>> The names of the buttons should be semantic, not color or positional. > >> ... unless the semantics vary between different parts of the same system, in >> which case no single semantic naming convention can suffice. > Exactly. No single naming scheme an suffice. Er... that's not *quite* what I said --- see above. > The names should be chosen > appropriate to the module within which they reside. This gives the problem of a user of multiple environments having to remember the physical-to-gesture mapping for each environment --- and the complexity increases for the environment having to remind the user. Help messages change from 'click the yellow mouse button' to 'perform your gesture X if you are in MVC; perform your gesture Y if you are in Morphic; perform your gesture Z if it's a full moon and high tide'. Hard to code, without careful consideration of the gesture interface and how the user help system can lift information out of the gesture mappings. > If you are doing a UI framework, like MVC or Morphic, > Then I would hope you would have some coherent semantics for your > input scheme. I agree, but... *within* each of MVC or Morphic (awkward when you flick between environments), or try to facilitate agreement *between* MVC and Morphic. I used to have three computer systems on my desk: Mac, Windows NT and SunVIEW/SunOS. Any coherent semantics goes out of the window at system boundaries. A Mac may be easy to use for experienced (or even novice) Mac users, but becomes hell when you interleave use of two other incompatible systems for about the same time. I needed coherence across these multiple interfaces. > (How fun would that be... towing > windows around your screen :-? ) Would the undo button need a sound sample with a loud beep and 'Warning... user reversing'? :-) > The right thing to do is to decide on the semantics you want, and then > figure out good UI gestures to invoke them. Yes, but the original discussion was about documentation of those gestures across multiple environments rather than the gestures themselves within a single environment. > How hard > would the piano be to play if all of the keys were laid out in a single > row, > rather than with the white-black scale-revealing system we use today? I'd prefer it. I know several (sloppy) keyboard players who just ignore the front half of a keyboard and use those nice evenly-spaced keys at the back --- especially those who work with singers who regularly want stuff dropped a semitone on gigs because their voice feels rough! As you say elsewhere, the UI has most variation. > Better still, provide an easy mechanism for users to customize and > extend their own mappings. Easy and *consistent*. It's this consistency that is hard to achieve across environments, but is what many users want --- witness fvwm95 on Linux, for example, for those MicroWeenies who can't let go of their Win95 interface. I was impressed with VisualWorks when it first came out; the idea of emulating the platform's look-and-feel was (and still is) neat. But Squeak has (two incompatible) cross-platform looks-and-feels; is this better (for cross-platform users), worse (for single-platform users), or just different? I don't know. - Peter

1 0

[BUG] [FIX] AcornFileDirectory root testing buglet
by Tim Rowledge 04 Oct '99

04 Oct '99

Oops. Found a wierd buglet exposed by the new and wonderful RISC OS4. Full fix really needs a VM roll, but the attatched changeset ameliorates the problem nicely. tim -- Strange OpCodes: SDP: Search and Destroy Pointer Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 842-6110 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim> Content-Type: APPLICATION/Octet-stream; NAME="AcornFileDirectory-fullNameFor." Attachment converted: Anon:AcornFileDirectory-fullNameFor. (????/----) (000144D1)

1 0

<test> don't bother reading
by John Duncan 03 Oct '99

03 Oct '99

Squeakie! -- "In any event, once Robert Craft forged the Stravinsky-Schoenberg axis in the 1950s and the eclecticism of the 1960s alleviated the austere serialism of the previous decade, the futures market in Hindemithian repose was struck by panic selling." -Glenn Gould

1 0

Slow posts (PWS)
by bolot 02 Oct '99

02 Oct '99

Has anyone figured this one out? If somebody posted a solution, etc., please disregard this message. It seems to be a combination of VM and Squeak networking problem. The problem shows up on NT, but not so much on Macs or UNIX. The culprit seems to be Socket>>waitForDataUntil: method (called from HTTPSocket>>getResponseUpTo: or PWS>>readRequest). Even if it succeeds, it seems to take an aweful lot of time to complete. We commented it out, and things work faster. Bolot

2 1

[UPDATES] 15 new ones for 2.6 alpha ...
by Dan Ingalls 02 Oct '99

02 Oct '99

.... many recent ones from all of you! For a good time, open a magnifier (morph) and choose 'be round'. Enjoy - Dan, for Squeak Central ---------------------------------- 1500alphaInstVarList-sw -- Scott Wallace -- 28 September 1999 Adds an option to have instance-variable lists (such as those presented in response to 'inst var refs' and 'inst var defs' queries) offered in alphabetical order, making it easier to locate what you're looking for if the list is long, such as in HandMorph; achieved by adding a new item at the top of the list which reads 'show alphabetially'. If there are only five or fewer instance variables involved, the user is spared the option of the alphabetical list." 1501caseSensitiveFind-sw -- Scott Wallace -- 28 September 1999 Adds a way for the 'find' command in text editing to be made case-sensitive. To activate this, set the preference 'caseSensitiveFinds' to true." 1502iconicButton-sw -- Scott Wallace -- 28 September 1999 Adds a SimpleButtonMorph subclass called IconicButton, which behaves like a SimpleButtonMorph but which shows a graphic rather than a string. This is in preparation for converting various textual controls over to being graphical. Note that if you have a textual control and wish to convert to a graphical control that looks the same (as a point of departure, pending artwork), there is a simple protocol for doing this. Evaluate, for example, self currentHand attachMorph: (IconicButton new labelFromString: 'Testing!') 1503littleCleanups-sw -- Scott Wallace -- 28 September 1999 (1) Keeps a bordered morph which has a symbol such #raised as its border color from dropping you into a debugger when you try to set its border color. (2) Removes superfluous NameStringInHalo.acceptContents. 1504FastUnsentMsgs-bf -- Bert Freudenberg -- 28 September 1999 Greatly speeds up Smalltalk>>allUnSentMessages etc. by using decent-sized IdentityDictionaries. 1505magnifier2a-bf -- Bert Freudenberg -- 28 September 1999 Fixes a buglet in the magnification menu code. Stops an infinite recursion when two magnifiers try to magnify each other. Subtle code for detecting animations elided by Dan I. 1506magnifier3-di -- Dan Ingalls -- 28 September 1999 A simple hack offering 'be round' / 'be square' option for magnifiers. Note resizing is only possible when the magnifier is square. 1507imgLibrary-tkLM 1508DropProjectDeps-di -- Dan Ingalls -- 26 September 1999 Eliminate registration of views as dependents of Projects. This used to have the bad effect of being an inward pointer into a world which, through owner pointers, tied down most of the morphic structure. The dependent relationship had only really been used to update labels, and to determine the view loc for project zoom effect. These are now handled by different mechanisms. 1509doubleClick-bf -- Bert Freudenberg (& sw) -- 28 September 1999 Enhances the method dispatch protocol for double-click so that if a morph registers for double-click and the ensuing mouse sequence is neither a double-click nor a single-click, the morph will subsequently be sent a sequence of #drag: calls, first with an attached mouseDown event, next with a series of mouseMove events, and finally with a mouseUp event. Extends DoubleClickExample to demonstrate use of methods click: and drag:. * On single click, changes border color. * Adds balloons to show what's going on. * Improves the #drag: behavior so mouseMove: needn't be used at all." 1510sysWindowMenu-sw -- Scott Wallace -- 29 September 1999 Adds a menu to the title bar of system windows, affording easy access to frequently-needed functions such as renaming, sending to back, and making unclosable (see below). Makes it possible for a system window to be designated as unclosable, in which case it will not sport a close-box (who among us has not inadvertently dismissed an important window because we happened to touch its close box?), and will not be closed by the wholesale window-menu commands 'delete unchanged windows'. Adds a command to the window menu making it easy to flip-flop between two windows that are stacked above one another. Note that a window's model is given the opportunity to enhance the window menu with its personal items if it so chooses." 1511BackOff-B 1512ClassOrderFix-RAA -- Bob Arning -- 1 October 1999 Improves the order of ChangeSet>>superclassOrder: for certain fileOut situations. 1513TrashSystemWindow-LC -- Leandro Caniglia -- 28 September 1999 Fix: Since ObjectExplorer doesn't handle keystroke events, #exploreFor: cannot use the default keystroke selector. The error becomes apparent when MorphicWrappers are installed. Fix: When allowSysWindowEmbedding is set to true and a System Window goes to the trash, an error occurs. The error becomes apparent when MorphicWrappers are installed. Change: Sometimes Morph|allMorphs is used instead of Morph|allMorphsDo:. The difference is that while allMorphs creates a new collection, allMorphsDo: enumerates each submorph without creating spurious collections." 1514DeclareTempFix-laza -- Alexander Lazarevic -- 1 October 1999 Ensures spaces around autodeclared temps.

1 0

ByteArray, wordAt/doubleWordAt
by Dino 02 Oct '99

02 Oct '99

What happened to ByteArray's messages in 2.5? Why was there a decision to take out wordAt: and doubleWordAt:?? I use these very frequently in my ICQ program... it would be best if they were still there. (I stuck them back in my 2.5 image... can't do ICQ without them) Dino

2 1

Re: Look and feel
by JArchibald＠aol.com 02 Oct '99

02 Oct '99

--> 10/1/99 8:50:00 PM EDT jddst19+(a)pitt.edu --> << Since you didn't mind snipping the verb, I said 'integrate' not 'replicate', which are different things. I thought the discussion was about doing the stuff in squeak that was done in the finder or explorer. If that is the case, you might want to bring in the icons that the system knows about. >> I would like to have a Squeak program which can be used to do some of the things I do with Windows desktop, but do some of them right (like remember layout of folders, etc.) I think using Window's own icons sounds fine to me (I don't have a problem with the icons). Also, I wouldn't insist that I could do everything--just like to have an environment which does an interesting subset of functions for me. (As an old Macintosh devotee, I would like a better Windows such as perhaps behave more like the Macintosh desktop). Jerry Archibald systemObjectivesIncorporated

1 0

RE: Look and feel
by John Duncan 02 Oct '99

02 Oct '99

> -----Original Message----- > From: JArchibald(a)aol.com [mailto:JArchibald@aol.com] > Sent: Friday, October 01, 1999 8:01 PM > To: squeak(a)cs.uiuc.edu > Cc: JArchibald(a)aol.com > Subject: Re: Look and feel > > > --> 10/1/99 1:38:10 PM EDT, jddst19+(a)pitt.edu --> > << all of the other stuff that makes up a look and feel of a > GUI operating system as we know it is kind of hard >> > > I don't think it's important to 'replicate' Windows desktop > or Macintosh Since you didn't mind snipping the verb, I said 'integrate' not 'replicate', which are different things. I thought the discussion was about doing the stuff in squeak that was done in the finder or explorer. If that is the case, you might want to bring in the icons that the system knows about. Perhaps you have a different idea. -John

1 0

[ENH] MessageTallyExplorer
by Michael Rueger 02 Oct '99

02 Oct '99

Hi all, inspired by the recent postings (thanks to Stephen and Doug!) about browsing a message tally I came up with a new one using the ObjectExplorer's tree. Enjoy Michael -- "To improve is to change, to be perfect is to change often." Winston Churchill +------------------------------------------------------------+ | Michael Rueger | | Phone: ++1 (818) 623 3283 Fax: ++1 (818) 623 3559 | +--------Michael.Rueger.-ND(a)online.disney.com----------------+ Attachment converted: Anon:TallyTree.zip (pZIP/pZIP) (00013DE1)

1 0

Jump to page: