Squeak-dev September 2003

squeak-dev@lists.squeakfoundation.org

163 participants
651 discussions

RE: [Morphic] About worlds
by Daniel Vainsencher 18 Oct '03

18 Oct '03

Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi, > > > Andreas Raab <andreas.raab(a)gmx.de> wrote: > > I understand the problem, but you're implicit about the solution - do > > you mean that instead of todays remove we would change the > > Morphs parent to be the world? > > No, what I'm saying is that the "owner" relationship should not be affected > at all when you "remove" a morph. Ah. It seems to me though we can keep the invariant you describe below (isParent(A,B) iff isSubmorph(B,A)) and still solve the problem. What do you think about fixing the issue the way I propose - every Morph always starts out with a parent (AstralWorld? WombWorld?), and can only change parents, but never remains orphaned. AFAICT, this would not change many implementation issues, but would require eventually changing the interfaces so that the remove would be replaced with #reParentTo: or something like it. > Secondly, there is a significant problem when creating new morphs. These > days, new morphs are not initialized in a definitive context (e.g., when > they are created their owner is nil) and one would need to provide > appropriate initializations. Most places don't care about this at all and I > would suspect that we'd get into serious trouble if we started relying on > all morphs being properly initialized ("properly" as in: having a definite > link to some world unless destroyed). How much more complex is it than adding owner _ WombWorld to Morph>>initialize? seems to make things simpler in that stuff is always initialized, except that initially it is to a world that isn't shown... Anyway, regardless of what solution is chosen, it doesn't seem to me like something that's impossible to do in 3.7 or 3.8... Ok, will pipe down and let the experts talk now... Daniel

11 35

[ENH] FileListEmptyDirectoryFix #2
by steve＠swerlingphoto.com 14 Oct '03

14 Oct '03

from preamble: "Change Set: FileListEmptyDirectoryFix Date: 28 December 2002 Author: Steven Swerling Currently in the hierarchy list FileList2, all folders have toggles that make them appear to have subfolders. This changeset removes the toggle from folders that do not contain subfolders. The old behavior of assuming that a subfolder exists is maintained in cases that would incur a performance hit (such as nonlocal directories). Changes this version: Catch Error in #hasContents causes default behavior (assume subfolder) instead of walkback."!

3 2

[BUG][FIX] A Morph that rendered by a TransformationMorph is not saved correctly
by Kazuhiro ABE 14 Oct '03

14 Oct '03

Hi all, A Morph that rendered by a TransformationMorph is not saved correctly. In this case, it needs to save a renderer instead of itself. 1. make an Ellipse morph 2. write a following script: Ellipse turn: 5 3. tick the script 4. save this morph by 'save morph in file' menu of debug halo 5. load the morph by 'load as morph' menu from filelist. 6. tick the script again 7. OOPS!! File in the attached changes, now saving and loading will work. Regards, Kazuhiro ABE NISHIHARA Satoshi

2 1

[ENH] SARInstallerEnhancements-nk
by ned＠bike-nomad.com 12 Oct '03

12 Oct '03

This should be added to the 3.6 update stream. I will post a corresponding version for 3.4/3.5 on SqueakMap. from preamble: "Change Set: SARInstallerEnhancements-nk Date: 21 July 2003 Author: Ned Konz 21 July: Fixed a bug in the DVS file-in. 5 July: More enhancements for the SARInstaller (for 3.5 or 3.6a). Adds a default (DWIM) mode in which SAR files that are missing both a preamble and postscript have all their members loaded in a default manner. Changes the behavior of #extractMemberWithoutPath: to use the same directory as the SAR itself. Added #extractMemberWithoutPath:inDirectory: Moved several change set methods to the class side. Made change set methods work with 3.5 or 3.6a/b Now supports the following file types: Projects (with or without construction of a ViewMorph) Genie gesture dictionaries Change sets DVS packages Monticello packages Graphics files (loaded as SketchMorphs) Text files (loaded as text editor windows) Morph(s) in files Now keeps track of installed members. "!

5 5

[ENH] SARInstallerExtensions-nk
by ned＠bike-nomad.com 12 Oct '03

12 Oct '03

from preamble: "Change Set: SARInstallerExtensions-nk Date: 20 June 2003 Author: Ned Konz This adds the ability for the SARInstaller to install Genie gesture dictionaries and Monticello files. "!

2 1

[FIX][ENH][3.6b] SARInstallerMC-nk
by ned＠bike-nomad.com 12 Oct '03

12 Oct '03

from preamble: "Change Set: SARInstallerMC-nk Date: 28 July 2003 Author: Ned Konz 28 July: * added Monticello version (.mcv) and package (.mc) loading * added prompts for downloading Monticello or DVS from SqueakMap if necessary * fixed bug with project loading * restored #fileIntoChangeSetNamed:fromStream: to instance side of SARInstaller for compatibility with older packages. * avoided generating empty change sets These are the changes between the v16 and v17 versions of the SARInstaller (previously posted to the 3.6b update stream as 5372SARInstallerFor36-16c). An updated version will be posted on SqueakMap. "!

2 1

[FIX] RelativeZipExtractFix-nk
by Ned Konz 12 Oct '03

12 Oct '03

This is a fixed version of the prior posting with this name. Doug noted that it was broken under Windows. from preamble: "Change Set: RelativeZipExtractFix-nk Date: 16 December 2002 Author: Ned Konz Version: 3.4b 16 Dec: This fixes a problem with re-opening a zip in an ArchiveViewer under Windows (by opening zips read-only), as well as fixing extraction with subdirectories under Windows. 13 Dec: This ensures that zip extraction relative to a given directory works properly, and should eliminate the infinite recursion noted on the Mac. It lacks AcornFileDirectory>>relativeNameFor: ; this should be added if necessary before adding to the update stream. "!

2 1

[FIX] WeakMessageSend2-nk-rw
by Ned Konz 12 Oct '03

12 Oct '03

from preamble: "Change Set: WeakMessageSend2-nk-rw Date: 8 December 2002 (v2) Author: Ned Konz and Rob Withers v2: Eliminated WeakMessageSendError; value* now silently returns nil if receiver or arguments have been GC'd. This defines a simple MessageSend where the receiver and arguments are held onto weakly. And it changes the NuBlue event registration to use the WeakMessageSends instead, so that subscribers can be garbage collected. "!

2 1

[BUG][FIX][TEST] Morph adding/removing
by Andreas Raab 12 Oct '03

12 Oct '03

Hi, The attached CS fixes various issues with Morph adding and removing the appropriate notifications. The attached test (which needs to go on top of the base image tests) illustrates the problem. The CS is slightly more complex than I liked but there simply wasn't another way of fixing that problem. As it turns out, the lack of a public #removeMorph: protocol leaves clients with all sorts of assumptions "what exactly is going to happen" if they just wish to remove a morph without dumping it (as is implied with #delete). In addition, the overrides of the privateRemoveMorph: protocols complicate matters even further which is why they have been moved into a separate notification protocol (#addedMorph: and #removedMorph:) which further subsumes the #addedOrRemovedSubmorph: protocol (as this was broken as well). All in all, the changes can probably be seen as part of MCP as they reformulate some notions that should have long been fixed in Morphic. Here is the preamble of the CS: "Change Set: MorphRemoval-ar Date: 10 August 2003 Author: Andreas Raab This change set fixes various of the issues for getting proper notifications when adding or removing morphs. What it does: * Morph>>removeMorph: has been added as a public method to remove a submorph from some parent (why wasn't this there before???). * Morph>>privateRemove: just removes the morph from its submorphs and is NOT intended for casual use (that's what we have #removeMorph: for). * Morph>>addedMorph: and Morph>>removedMorph: have been introduced for clients which need to know about adding/removing morphs * Morph>>addAll: and friends have been updated to adhere to the new protocols while preserving their optimized implementations. * Various places have been fixed to use #removeMorph: instead of #privateRemoveMorph: and to implement the #removedMorph: notification. * #privateRemoveMorph: as well as #addedOrRemovedSubmorph: have been deprecated. " Cheers, - Andreas

12 37

[ENH][REFACTOR] PostscriptCanvasesCleanup
by adspitz＠yahoo.ca 12 Oct '03

12 Oct '03

from preamble: "Change Set: PostscriptCanvasesCleanup Date: 2 August 2003 Author: Adam Spitz Just a bunch of recategorizations for methods that should be extensions of the Morphic-Postscript Canvases package. Still leaves some external references (all of them menu items); we'll deal with those separately."

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
66
Older →

Jump to page: