Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

Re: MVC is Dead?
by Dan Ingalls 01 May '00

01 May '00

[A clarification -- when we at Squeak Central (SqC) refer to "MVC", we are usually referring to the "old ST-80 viewing structures" and their control regime (View/Ctlr, SSView/Ctlr, and ControlManager). We consider the model/dependents architecture and change/update protocols to be of enduring value in Squeak as in MVC]. >At 09:34 PM 2/1/00 -0600, Les Tyrrell wrote: >>If the support is there to power Morphic, I'd think that the >>support will always be in place to resurrect MVC, should it >>be dropped from the baseline. >[snip] "R. A. Harmon" <harmonra(a)webname.com> replied... >I don't share your optimism on this point. I think it would slowly become a >dead path. Less bugs would get fixed, less enhancements get added, less >people use it, so less bugs would get fixed, less enhancements get added, >less people use it, . . . . It appears to me that additional "widget?" are >added to morphic but not in a way that they can be used in MVC--I'm not >familiar enough with morphic to tell for sure. This is already the case -- MVC is currently maintained for backward compatibility (with documentation, etc) -- it is not the site of most enhancements and of Squeak's general forward motion (animation, 3D, music and sound support, etc). >I think this is a route that will diminish Squeaks accessibility to folks >new to Smalltalk as most books on Smalltalk and code freely available (other >dialects) don't use morphic. Trying to translate MVC to morphic adds a >level of complexity to learning from the books and code. This is enough to >dissuade someone from getting over the OOP-think hump. This is why we have kept MVC so far. That familiarity and compatibility with other STs is a valuable component in the overall synergy. Regarding the OOP-think hump, we at SqC consider NEITHER Morphic nor MVC to be adequate. We still feel that an entirely new approach is needed here -- along the lines of Morphic viewers somehow integrated with a real inspector/browser/debugger, with maybe a few things borrowed from Fabrik and Morphic Wrappers. Wish us luck (or beat us to it!). >I think the newbies and tools are both useful in getting to the next plane. Absolutely. We do not plan to decommission (excise from the release) MVC until the time when nearly everyone who uses Squeak does so as an environment unto itself, not as a free alternative to other similar Smalltalks where MVC compatibility is important. We feel that this could happen within the current year (but we had the same feeling a year ago ;-). Whenever the time comes, we will produce a "Last Picture Show" image that is the cleanest and most complete MVC-based image possible, so that it can be used and maintained indefinitely by motivated MVC survivalists. >>Isn't Morphic about due for the long-awaited refactoring? Yes, indeed. This is another nice thing about retaining MVC for a while. It gives us a place to stand when making major changes to Morphic. - Dan

2 1

Re: Palm drops 68K in Favor of ARM - Implications for Squeak?
by John.Maloney＠disney.com 01 May '00

01 May '00

Thanks for passing along this news. The Palm has long been a natural Squeak target, but the low performance Dragonball processor made it unattractive. Worse, the Palm OS memory model made it difficult to get a single contiguous block of RAM in which to put Squeak's object heap. An ARM processor (StrongARM or otherwise) would address the first problem and I suspect that Palm would also address the second problem when they migrate to the new processor. Applications such as MP3 players and speech recognition would be difficult to write using the current Palm memory model, and I don't think ARM architecture offers any particular incentives to use small memory chunks the way the 68K architecture does. Meanwhile, the new Compaq Aero based on the StrongARM sounds like it might make an excellent Squeak platform. There are pdf files at: ftp://ftp.compaq.com/pub/products/handhelds/pocketpc.pdf ftp://ftp.compaq.com/pub/products/handhelds/famchart.pdf -- John At 12:58 PM -0700 4/28/00, John-Reed Maffeo wrote: >http://news.cnet.com/news/0-1006-200-1752075.html?dtn.head

1 0

[FIX]New Morph menu TextSupport
by Karl Ramberg 01 May '00

01 May '00

This fix removes two items from the New Morph menu / Text Support. Either of the items funktion alone and are useless. This just confuses people when trying to add text to a book or something. Use the textMorph in the basic sub menu. Karl 'From Squeak2.8alpha of 19 February 2000 [latest update: #2052] on 1 May 2000 at 1:44:56 pm'! !TextMorph class methodsFor: 'as yet unclassified' stamp: 'kfr 5/1/2000 13:42'! includeInNewMorphMenu "OK to instantiate" ^ true! ! !StringMorphEditor class methodsFor: 'as yet unclassified' stamp: 'kfr 5/1/2000 13:41'! includeInNewMorphMenu "Not to be instantiated from the menu" ^ false! ! !TextMorphForEditView class methodsFor: 'as yet unclassified' stamp: 'kfr 5/1/2000 13:41'! includeInNewMorphMenu "Not to be instantiated from the menu" ^ false! !

1 0

displaying a thingie
by Lex Spoon 01 May '00

01 May '00

There are now three places where Squeak is presented with binary data and a guess at a content type: Scamper, FileList, and now Celeste. We also have three independent ways to deal with this: MailMessage>>bodyFormattedText, FileList>>fileListMenu, and Scamper>>displayDocument:. This situation is crying out for unified handling. I don't have a specific proposal, but the following seem like good things to keep in mind: 1. There should be a way to add new content-type handlers on a package-by-package basis. 2. Let us absolutely *not* use this stuff internally--classes are much better than content-types. 3. The user should get a choice about how the document is treated, but we should make it easier to do the most obvious thing. For example, if it's image/foo, then make it easy to view the data as an image. 4. One possible definition of "view", is "generate a Text instance, possibly with embedded morphs". Another is "just give me a morph!". -Lex

1 0

MailMessage
by Lex Spoon 01 May '00

01 May '00

Sorry to be spamming people if this is boring, but I wanted to point out that this last changeset makes MailMessage a very nice general-purpose tool--it's not just for Celeste anymore. 1. You can do "MailMessage from: text" to parse anything in mail-message format, including HTTP responses or NNTP responses. This includes removal of content-transfer-encoding such as base64. 2. When you query a header field, you now get a MIMEHeader instance, which includes the paramaters in addition to the core value. 3. You can generate a view of such a message with "msg bodyTextFormatted" or, if you want the headers, too, "msg formattedText". You can open a viewer on this with "msg viewBody". -Lex

1 0

Re: RE: World sensitivity (was Re: [updates] 35 more for 2.8alpha)
by Bob Arning 01 May '00

01 May '00

On Sun, 30 Apr 2000 20:13:23 +0200 Stefan Matthias Aust <sma(a)3plus4.de> wrote: >Actually, I think it isn't needed. It's a handy reference but every morph >can be asked for its world by using #world already. Assuming that morph is in the world already. >To add new morphs to >the world, one could ask the (actually one) hand morph for the >world. (BTW, I bet that not all code in morphic can deal with the fact >that there could be more than one hand) > >David, I think you're right. One could remove the global and replace its >references with a few new methods. That's a good idea, but it still leaves the question of where those few methods will find the world. Object>>currentWorld starts out: World ifNotNil: [^ World]. Cheers, Bob

2 2

[FIX]Typing follows mouseDown not mouseEnter/mouseLeave
by Karl Ramberg 01 May '00

01 May '00

> Now I commented out the #mouseEnter and #mouseLeave in PluggableTextMorph > and PluggableListMorph and everything seems to funktion fine and the way I > would expect it: > The text I click at to edit will continue to recive typing till I click at > something else. > > Maybe it's just me ? > Karl > > Karl Ramberg wrote: > > > Found it my self and it seems to be a feature of PluggableTextMorph. > > I find this feature really annoying. Maybe a preference is in place ? > > > > Karl > > > > Karl Ramberg wrote: > > > > > Try this. > > > Open a Workspace. > > > Open a TextMorph. Click on the TextMorph. Start typing. Move the mouse > > > over the Workspace while you continue typing. The Workspace starts > > > reciving > > > the typing. > > > Is this a feature or a bug in the HandMorphs keyboardfocus. Or is it > > > somewere else. > > > I have a hard time tracing this one. > > > > > > :-( > > > > > > Karl > Try this. > Open a Workspace. > Open a TextMorph. Click on the TextMorph. Start typing. Move the mouse > over the Workspace while you continue typing. The Workspace starts > reciving > the typing. > Is this a feature or a bug in the HandMorphs keyboardfocus. Or is it > somewere else. > I have a hard time tracing this one. > > :-( > > Karl

2 1

OFFTOPIC applefile (was Re: [Enh] Music Editor)
by danielv＠netvision.net.il 01 May '00

01 May '00

Just wondering, could some Mac guy explain what this appledouble stuff is? can help but wonder, we'll have to make them transparent in Celeste someday... ;-) Mark Guzdial <guzdial(a)cc.gatech.edu> wrote: > --============_-1255180694==_============ > Content-Id: <v04210119b52f73393641(a)[130.207.3.227].0.0> > Content-Type: multipart/appledouble; boundary="============_-1255180694==_D============" > > --============_-1255180694==_D============ > Content-Transfer-Encoding: base64 > Content-Type: application/applefile; name="%MusicEditorApril27.zip" > Content-Disposition: attachment; filename="%MusicEditorApril27.zip" > ; modification-date="Thu, 27 Apr 2000 16:00:27 -0400" > > AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAABYAAAAJAAAAVAAAACAA > AAAIAAAAdAAAABBNdXNpY0VkaXRvckFwcmlsMjcuemlwWklQIFpJUCABAAKcA8AAAAAA > AAAAAAAAAAAAAAAAAAAAmyCbAJsgm0ttDAAAnEoq

2 1

Re: [BUG] Update-from-server time slows down after update 1800
by Bob Arning 01 May '00

01 May '00

On Sun, 30 Apr 2000 19:51:28 -0400 (EDT) Doug Way <dway(a)mat.net> wrote: >I happened to try using "update from server" to update a Squeak 2.7 image >to 2.8alpha. > >For updates 1765 to 1799, there is about a 2 second delay between the time >one progress bar dissappears and the next one appears. But after update >1800, the delay jumps up to about 20 seconds between every update. This >is on Windows NT. > >But I tried updating from the exact same image on SGI/Irix, but it's fine, >the delay stays at about 2 seconds between updates. > >Then I figured I might as well try my Mac at home (with a 56K modem), and >it seems to have the same problem that Windows has. Weird. > >I did a alt-. during the 20 seconds, and it's sitting in >Semaphore>>waitTimeoutMSecs:, where msecs is 20000. (kind of makes sense) > >(On Windows NT, I also tried updating from a saved 2.8alpha image which >happened to start at update 1919... this one only had 2 second delays.) > >Anyway, the problem is pretty annoying... basically, if you try to update >a 2.7 image to 2.8alpha on Windows or a Mac, it takes a *long* time, about >90 minutes longer than it should. Hi Doug, What I see is this: cs 1800 includes in its postscript Smalltalk recreateSpecialObjectsArray. which effectively eliminates the VM's knowledge of where the semaphore for NetNameResolver is. As a result, even though subsequent NetNameResolver requests for the address of the server containing the updates succeed, the VM doesn't know whom to notify. Thus the full 20 second wait happens before NNR sees the success. don't see a real pretty solution, but one thaing that helps is changing ResolverSemaphore waitTimeoutMSecs: (deadline - Time millisecondClockValue). to ResolverSemaphore waitTimeoutMSecs: 100. in the following: NetNameResolver class>>waitForResolverReadyUntil: NetNameResolver class>>waitForCompletionUntil: An alternative would be for cs 1800 to use something a little less drastic than #recreateSpecialObjectsArray since the goal in this case is to *add* information, not to *remove* it. Cheers, Bob

1 0

Re: [ENH] Celeste receives attachments
by danielv＠netvision.net.il 01 May '00

01 May '00

[Displaying attachments inline - better than menu in TOC] I agree attachments should display a token, not encoded contents. One thing I thought on this topic - it's important to allow the user several options when more than one is relevant (a gzipped changeset attachment? should that be just saved? or maybe also decoded? or maybe it should be decoded and filedIntoItsOwnChangeset?). I won't do the attributed text - I may have an alternative but that's a bit wild and definitely farther off - I thought MIMEParts could display themselves in a style similar to SyntaxMorphs, except they'd have a part-type sensitive menu, and be editable. Anyway, I'm in an optimizing - not interface - kind of mood, so I'm not going back to writing interface at least until I've eliminated all those long saves after every twitch ;-)... Bob Arning <arning(a)charm.net> wrote: > On Fri, 28 Apr 2000 09:56:19 "Lex Spoon" <lex(a)cc.gatech.edu> wrote: > >As for the UI, I've been thinking that instead of a menu, a good way to > >handle attachments would be to make a link within the text which is > >hyperlinked to the attachment. Clicking on the link would give you a > >small menu with things like "open in window" or "save to file". > >Really, it should be a very similar menu to the one that FileList has. > > > >To make such a link, one first makes a new subclass of TextAttribute > >with the relevant instance variables (probably data, content-type, and > >default file name). Adding the attribute to your text is a small > >challenge, but AttributedTextStream should be useful here. > > Here are some snippets that I use. The full context is available at > > http://www.charm.net/~arning/SqMailServer.24Apr1833.cs > > It could use a little polish, but it keeps me happy WRT attachments. > > Cheers, > Bob > > ===== code folows ===== > 'From Squeak2.8alpha of 13 January 2000 [latest update: #2042] on 30 April 2000 at 11:39:54 am'! > Object subclass: #AttachedFileRepresentation > instanceVariableNames: 'stream fileName fileType creator finderFlags dataStart dataLength resourceStart resourceLength ' > classVariableNames: '' > poolDictionaries: '' > category: 'Collections-Streams'! > > !AttachedFileRepresentation methodsFor: 'as yet unclassified' stamp: 'RAA 3/17/1999 18:02'! > contents > > ^stream contents copyFrom: dataStart + 1 to: dataStart + dataLength! ! > > !AttachedFileRepresentation methodsFor: 'as yet unclassified' stamp: 'RAA 2/28/1999 21:19'! > defaultFileName: aString > > fileName ifNil: [fileName _ aString]! ! > > !AttachedFileRepresentation methodsFor: 'as yet unclassified' stamp: 'RAA 2/28/1999 21:18'! > printLinkOn: aStream > > aStream > nextPutAll: '<file:',(fileName ifNil: ['unknown']),'>' > ! ! > > !AttachedFileRepresentation methodsFor: 'as yet unclassified' stamp: 'RAA 7/17/1998 00:32'! > setStream: s > fileName: fn > fileType: ft > creator: cr > finderFlags: ff > dataStart: ds > dataLength: dl > resourceStart: rs > resourceLength: rl > > stream _ s. > fileName _ fn. > fileType _ ft. > creator _ cr. > finderFlags _ ff. > dataStart _ ds. > dataLength _ dl. > resourceStart _ rs. > resourceLength _ rl. > ! ! > > !AttachedFileRepresentation methodsFor: 'as yet unclassified' stamp: 'RAA 4/21/2000 11:20'! > view > > | fn dir fn2 i | > "StringHolder new contents: self contents; openAsMorphLabel: fileName" > > fn _ fileName. > (fn isNil or: [fn isEmpty]) ifTrue: [ > fn _ '???' > ]. > dir _ FileDirectory default. > fn2 _ fn. > i _ 0. > [dir fileExists: fn2] whileTrue: [ > fn2 _ fn,'.',(i _ i + 1) printString > ]. > ( > FileList > openMorphOn: (dir newFileNamed: fn2) > editString: self contents > ) openInWorld! ! > > > !EekMailFormatter methodsFor: 'as yet unclassified' stamp: 'RAA 7/17/1998 14:49'! > makeStyleLinkFrom: start to: stop numbered: anInteger in: aText > > aText > addAttribute: (TextDoIt evalString: 'self handleAttachmentLink: ',anInteger asString) > from: start > to: stop > ! ! > > !EekMailFormatter methodsFor: 'as yet unclassified' stamp: 'RAA 2/28/1999 21:19'! > parseApplicationFrom: aStream withDelimiter: delimiter with: localHeaders > > | thereIsMore attachmentOnly theAttachment attachStart localDisposition localFileName | > > thereIsMore _ self > skipBodyFrom: aStream > upTo: '--',delimiter > or: '--',delimiter,'--' > addingTo: (attachmentOnly _ ReadWriteStream on: ''). > theAttachment _ self parseAttachment: attachmentOnly with: localHeaders. > localDisposition _ localHeaders findHeaderType: 'Content-Disposition'. > localFileName _ self parse: localDisposition forKeyword: 'filename='. > theAttachment defaultFileName: localFileName. > > attachments add: theAttachment. > attachStart _ outputStream position + 1. > theAttachment printLinkOn: outputStream. > outputStream cr. > restylingRanges add: {#makeStyleLinkFrom:to:numbered:in:. attachStart. > outputStream position - 1. attachments size}. > ^thereIsMore > > ! ! > > > !EekMailWindow methodsFor: 'as yet unclassified' stamp: 'RAA 7/17/1998 15:05'! > handleAttachmentLink: info > > (currentMessage attachments at: info) view.! !

1 0

Jump to page: