Squeakfoundation December 2002

squeakfoundation@lists.squeakfoundation.org

24 participants
33 discussions

RE: [Squeakfoundation]Ad-hoc final harvesting for 3.4
by Daniel Vainsencher 10 Dec '02

10 Dec '02

Cool! I think many more things in Squeak should be happening asynchronously. I've been trying to figure out a place to hook that up that wouldn't require people to be always forking things explicitly, and the event handling mechanism sounds like a good solution to that problem... Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Rob, > > > 3) Weak message sends and conversion of the NuBlu events to use them. > > Ever looked at EventMessageSet?! I did this for probably the exact same > reasons that you are using weak messages sends now. And yet, neither is > not going to solve your problems ;-( > > Seriously, did you ever find the time to look closely at how this is > handled in the event stuff that I did a while back (it is now in > Croquet)?! The problem with the NuBlue (and any other event) framework > is that it does not allow the subscriber to reflect about its > subscriptions. In other words, if I have a window and a button and say: > > button on: #click send: #close to: window. > > then what I say is that the button should tell the window to close when > I click on it. And of course, the button has to know the window in order > to do this. And while this is a nice first-order theory it is > problematic if we close that window by any other means (in which case we > may want to stop the subscription) and naturally, the button will hold > on to the window for the rest of its live. This is the problem which you > are trying to solve with weak references but it is conceptually wrong. > > The problem is that #click is really a trigger for a method (script) in > the window which may happen asynchronously. And this script is clearly > owned by the window and not by the button and that's what all of these > event frameworks never take into account. With the model that I built > this is different (and not only in this respect ;-) Here, the subscriber > always remembers its registrations (messages) *strongly* and the > publisher always remembers the subscriptions *weakly* (by default). This > has various advantages, an obvious one being that if the subscriber goes > away so does its subscription (this is what you are trying to do with > weak refs) and the publisher is not bothered by it [*1]. However, what's > even more important is that in a case like the above, the window can > reflect about its subscriptions and cancel them if it gets closed > without having to know any "external subscriptions" (e.g., added by > someone else). > > [*1] I find it _extremely_ questionable to raise an error by default > here. There may be a few applications which need to know about it but by > and large I would expect people to get really confused and say "yeah, of > course it's gone that's what it *ought* to do". For those who do it is > utterly trivial to provide a different subscription (MessageSend > subclass). > > In Croquet, the above example would look like: > > window startScript: #close when: {button. #click}. > > which tells the window to start the #close script when the button is > clicked. [Slight side note here: #startScript denotes an asynchronous > signal; #runScript a synchronous one. So the exact equivalent would be > "window runScript: #close when: {button. #click}" but I haven't used > synchronous signals in about a year except for debugging]. The magic is > now that the window could do something like > > Window>>close > super close. "to get rid of it" > self stopScript: #close. > > in order to cancel its "subscription" (I don't like the term in this > context but it's useful to show the similarities). Or even more > radically (and that's code I am really using): > > Window>>destroy > "I shall be destroyed. Stop all scripts" > self scripts do:[:script| self stopScript: script]. > > This latter makes it impossible to have any pending references if the > window should be destroyed. But there is even more fun stuff you can do > with this. Consider that if we close the window, we want to put into the > trash and be able to get it back. The button should of course work if we > get it back. How can we solve this problem?! Well, here's one solution: > > Window>>initialize > "Set me up in a way that I will only run #close > scripts while I am in the world" > "pause close script when I get out of the world" > self pauseScript: #close when: {self. #outOfWorld}. > "resume close when I get back in" > self resumeScript: #close when: {self. #intoWorld}. > > And this will work for any number of buttons who want to send close to > the window. All of this is only possible because the *window* knows > about the scripts (subscriptions) and not the button. > > There are even more advantages to this (such as for serialization) but I > think this will get you an idea why I think that any kind of > subscription mechanism that doesn't give the subscriber access to its > subscriptions is ultimately doomed to fail - you simply cannot write > fault-tolerant code if you cannot reflect about them. > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]Ad-hoc final harvesting for 3.4
by Daniel Vainsencher 10 Dec '02

10 Dec '02

Hmm, now looking at the calendar, I notice that it's the 10th. We've announced vaguely the release goal of end of the year. Leaving a week for a gamma phase, with only critical fixes and changes of help texts and such, that leaves slightly less than two weeks of this beta period. We'll need some time for people to review something stable and test further fixes needed on top of that. So I'm amending my mail from before. I now think the following things, though desirable, should not go into 3.4, because they're not stable enough yet - * Thierry Reignier's keyboard control of HierLists. * Torge.Husfeldt's ShrinkingSelection * Andres Valloud's LargeIntegerHash * Steve's lines in HierLists. * Brent Vukmers previewer in world menu. We should just notify the authors so they can make them ready for early 3.5a. Proposed time line - * 15.12.02 - those things we're sure about out in the external stream. * 22.12.02 - gamma * 29.12.02 - if it's ready, declare final. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > Ned Konz wrote: > > > > On Saturday 07 December 2002 09:22 pm, Doug Way wrote: > > > [FIX] DNSerror-ls (3 November 2002) * Lex Spoon (3 November 2002) > > > http://swiki.gsug.org:8080/sqfixes/2735.html > > > - Discussed in Goran's post. Ned mentioned that he'd rather see > > > httpGet* signaling Exceptions. Is that a simple change to make > > > now, or should we go with Lex's fix for now (to fix the hanging > > > problem), and add Exceptions later? > > > > I already have httpGet* signaling exceptions for all but DNS errors. > > This is in a fix that I believe is in SqueakMap. > > > > This fix touches the same methods, and should be merged with mine if > > we're going to use it. > > Ok, I guess we need to decide on this one. I would say that if you want to merge your changes with Lex's fix and submit that (assuming it still fixes the hanging problem and doesn't add much complexity), then we could try incorporating that. Otherwise, we should just go with Lex's fix, and then clean it up further in 3.5alpha. > > > > [FIX][3.2][3.4a] ArchiveFixes2-nk (12 November 2002) * Ned Konz (12 > > > November 2002) > > > http://swiki.gsug.org:8080/sqfixes/2748.html > > > > As noted, this is also included in SARInstaller. Though I'm the > > author, I'm also the author of the original code it fixes. I > > personally think it should go in, as it helps cross-platform usage of > > zip files. But I do think that someone else should look at it. > > I can take a look at this one. > > - Doug > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]Ad-hoc final harvesting for 3.4
by Daniel Vainsencher 10 Dec '02

10 Dec '02

Ok, then that's my position too - consider adding Torge's selection code into 3.5a, after some more inspection. About ParensBlinking, I wonder - why shouldn't it stay a package? Daniel Avi Bryant <avi(a)beta4.com> wrote: > > > On Mon, 9 Dec 2002, Daniel Vainsencher wrote: > > > Avi, it's not clear whether you've looked at Torge's code, or just want > > the functionality. If not, could you have a look and let us know what > > you think? > > Daniel, > > I didn't have time to thoroughly audit the code. It does look reasonable > and well factored, and it comes with SUnit tests, so I generally trust it. > However, it does touch an awful lot of code (7 classes and lots of > methods), and given that I would recommend bringing it in for 3.5 rather > than 3.4. > > Avi > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]Ad-hoc final harvesting for 3.4
by Daniel Vainsencher 10 Dec '02

10 Dec '02

Avi, it's not clear whether you've looked at Torge's code, or just want the functionality. If not, could you have a look and let us know what you think? Daniel Avi Bryant <avi(a)beta4.com> wrote: > > On Sun, 8 Dec 2002, Doug Way wrote: > > > [Fix][Enh]ShrinkingSelection(was: Re: Behavior of Shift+arrow) (24 > > November 2002) * Torge.Husfeldt (24 November 2002) > > http://swiki.gsug.org:8080/sqfixes/2825.html > > - This is very nice... hmm. I tested this a bit, and it works. I'd > > even prefer to see this preference turned on by default. The other > > added preference (wordStyleCursorMovement) is a good idea, too (though > > it could be off by default). Still, this involves a fair amount of > > changes, and perhaps should wait until 3.5alpha for that reason. > > Whevever this goes in - while we're modifying ParagraphEditor, I would > push for my paren-blinking changeset to go in as well (modified to use a > preference). It's completely stable and adds inobtrusive but quite useful > functionality. > > Personally, I'd like to see these get adopted as soon as possible - better > text editing significantly imrpoves the out of box experience, IMO. > > $0.02 > Avi > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]Ad-hoc final harvesting for 3.4
by Daniel Vainsencher 10 Dec '02

10 Dec '02

Commenting about many but not all of the changes noted. BTW, do we want to CC the authors, or do we assume they're reading the list? Doug Way <dway(a)riskmetrics.com> wrote: > 1. Ones that I think could probably go in 3.4: > ---------------------------------------------- > > [ENH] Add lines to hierarchy views (5 December 2002) * sps2000(a)mail.com > (5 December 2002) > http://swiki.gsug.org:8080/sqfixes/2877.html > [ENH] LinesInHierWIcon-nk (5 December 2002) * Ned Konz (5 December 2002) > http://swiki.gsug.org:8080/sqfixes/2879.html > [ENH] HierListsWithIcon-nk (4 December 2002) * Ned Konz (4 December 2002) > http://swiki.gsug.org:8080/sqfixes/2870.html > - A few of us agreed that we'd like to see these go in. Perhaps the > only question is whether they're reasonably safe for 3.4beta. I think > that they probably are, but more opinions are welcome. (Although I do > notice that scrolling large lists in the object explorer (e.g. the > Smalltalk dictionary) is a bit slower now with the lines drawn, as Ned > mentioned. And, in certain cases, the dreaded "gribbleys" show up, > although they're hard to notice because the lines are faint to begin > with. These problems aren't too serious and may be easy to fix. Or > maybe we could just add the Icon stuff for now. Or just put it all off > until 3.5alpha. :-) ) Doug, can you give Steve a recipe to reproduce gribbleys, and see if this can be fixed? I didn't notice anything... > [FIX] Translation to iso-8859-1 encoding in Scamper (16 November 2002) * > Boris Gaertner (16 November 2002) > http://swiki.gsug.org:8080/sqfixes/2770.html > - It sounds like this one has been tested pretty well. With this fix, > if I look at > http://map2.squeakfoundation.org/sm/package/4f0b9db6-8add-43aa-8d6b-53e6a0e… > in Scamper, Göran's name now shows up correctly. I think in scope it is a bit non-essential (maintain Scamper as a package, anyone?), but it works and the code looks simple too, so lets add it. > [FIX] UUID-Fix-CdG (19 November 2002) * cg(a)cdegroot.com (19 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2786.html > - Discussed in Goran's post. It sounds like there is some agreement > that we should go with this simple fix for now, and fix Random sometime > in the future, since that is much more involved. Ok, has this been tested by someone other than the poster for all the relevant situations (unix/notunix with sound input/neither of the above)? Other than that, I'd take it, as a temporary solution. A real UUID generator accessing the MAC of an interface and so forth would be better. > 2. Ones that I think could probably wait until 3.5alpha for > consideration, or have already been fixed: > -------------------------------------------------------------------------- > > [ENH] Comma concatenation for Object (6 December 2002) * Brent Pinkney > (6 December 2002) > http://swiki.gsug.org:8080/sqfixes/2883.html > - Seems like a significant (and possibly controversial) change for a > beta release. I think it would hide bugs quite often, and doesn't solve a serious problem, given {} notation. I don't think it should be included. > [GOODIE] Matrix-raok (28 November 2002) * ok(a)cs.otago.ac.nz (28 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2838.html How about removing array2d from the image? seems to me this could be an SM package. There is one reference to array2d in the image, it is from a method with no senders. > [ENH] ANSI compatibility (24 November 2002) * Alain Fischer (24 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2820.html > - Should probably wait until 3.5alpha, but it would be worth considering > then (not necessarily all of it). I agree. Also, it's a big change set with many different things - - Improvements to TestRunner (Should be considered together with the TestRunnerEnhancements by Ned). - New date related classes, including DataAndTime (which we might want to start using generally in the image), and including a few utility classes. This might require a little upheaval, and I would discuss them for 3.5. - Some arithmetic classes, including a new kind of number. Probably could go into 3.4, but I'd value the opinion of other people that have an interest in numbers and the standard. - A set of new exceptions which should be used wherever specific kinds of errors occur. The image might have to be prepared to catch them. > 3. Ones that I leave the rest of you to decide: > ----------------------------------------------- > > [FIX][3.4] Enhanced-IRC with dynamic open menu (4 December 2002) * Brent > Vukmer (4 December 2002) > http://swiki.gsug.org:8080/sqfixes/2872.html This is not a fix to the image, it is to a package. Not our call.. but I'd definitely like to see it applied. > [FIX] Celeste in MVC (4 December 2002) * Bruce ONeel (4 December 2002) > http://swiki.gsug.org:8080/sqfixes/2864.html I'm against. Celeste should work in MVC, but this implementation adds too much complexity to Celeste. It would be better to either fix some of the small missing things in MVC, or to separate the compatibility stuff so that Celeste doesn't know what interface it's running. More generally speaking, over all it adds complexity, just so a package can run better. This is the sort of place where we should remove the package, not fatten the image. (yes, I'll work on making Celeste removable so we can do this). > [ENH] Keyboad navigation for SimpleHierarchicalListMorph (28 November > 2002) * Thierry Reignier (28 November 2002) > http://swiki.gsug.org:8080/sqfixes/2841.html > - Seems kind of useful. Ah, I hadn't seen this, I've wanted it it for quite a while. I think we definitely need it, except that in my brief testing, I couldn't get left/right/cr to do anything (in other words, expand/collapse doesn't work). > [Fix][Enh]ShrinkingSelection(was: Re: Behavior of Shift+arrow) (24 > November 2002) * Torge.Husfeldt (24 November 2002) > http://swiki.gsug.org:8080/sqfixes/2825.html > - This is very nice... hmm. I tested this a bit, and it works. I'd > even prefer to see this preference turned on by default. The other > added preference (wordStyleCursorMovement) is a good idea, too (though > it could be off by default). Still, this involves a fair amount of > changes, and perhaps should wait until 3.5alpha for that reason. I'd want to get this into 3.4 if someone else familiar with the selection code to vet it. Otherwise, I'd propose to put it in 3.5a, with any new preferences turned on to get them exercised (generally speaking, we can tweak preferences to be "mainstream" in gamma releases, but should use alpha time to get feedback on the weirder variations). > [ENH] LargeInteger hash (24 November 2002) * Andres Valloud (24 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2822.html In general looks like a good idea. Issues - * What sort of testing has this had? Andres? anyone else? * There are question marks in Interpreter>>obsoleteNamedPrimitiveTable. It's not clear to me what decisions are still not clear, and whether this causes an incompatibilty with other VMs, because of the name change to the existing primitive. > [GOODIE] WatchWindow-nk (24 November 2002) * Ned Konz (24 November 2002) > http://swiki.gsug.org:8080/sqfixes/2821.html > [GOODIE] MorphInspector-nk (24 November 2002) * Ned Konz (24 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2819.html > [ENH] BrowseModelClass-nk (24 November 2002) * Ned Konz (24 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2817.html > - These are some longstanding enhancements posted by Ned, probably in > response to my "call for submissions". None of them look like > must-haves to me, although I kind of like the WatchWindow... that might > be worth adding to the base release. It adds "watch it" to the do- > it/print-it/inspect-it menu... is it worth its weight? A worthy package today, might go into configurations tommorrow. > [FIX] MessageSetDragFix-nk (24 November 2002) * Ned Konz (24 November > 2002) > http://swiki.gsug.org:8080/sqfixes/2818.html > > [ENH] image previewer in world menu --> open... (23 November 2002) * > Brent Vukmer (23 November 2002) > http://swiki.gsug.org:8080/sqfixes/2811.html Does the job. Many changes for FileList2, can anyone comment on those? It seems to conflict with the hierarchy navigation changes discussed - when I first load the keyboard navigation, then this changeset, opening the previewer caused an infinite regression, and image death, with this stack dump - 1087678728 Object>canDiscardEdits 1087678636 [] in Object>canDiscardEdits 1087678544 SequenceableCollection>do:without: 1087678452 Object>canDiscardEdits 1087678360 Model>canDiscardEdits 1087678268 StringHolder>okToChange 1087678176 FileList2>directory: 1087678084 FileList2>setSelectedDirectoryTo: 1087677992 SimpleHierarchicalListMorph>setSelectedMorph: 1087667708 [] in IndentingListItemMorph>openPath: 1087667608 IndentingListItemMorph>withSiblingsDo: 1087667516 IndentingListItemMorph>openPath: 1087667104 [] in IndentingListItemMorph>openPath: 1087667000 IndentingListItemMorph>withSiblingsDo: 1087666908 IndentingListItemMorph>openPath: 1087656424 [] in IndentingListItemMorph>openPath: 1087656316 IndentingListItemMorph>withSiblingsDo: 1087656224 IndentingListItemMorph>openPath: 1087655584 [] in IndentingListItemMorph>openPath: 1087655380 IndentingListItemMorph>withSiblingsDo: 1087655288 IndentingListItemMorph>openPath: 1087655172 SimpleHierarchicalListMorph>update: 1087655472 [] in Object>changed: 1087655068 DependentsArray>do: 1087654976 Object>changed: 1087654844 FileList2>postOpen 1087488192 FileList2 class>morphicViewImageViewerWithPreview 1087488008 FileList2 class>openMorphicViewWithPreviewInWorld > [FIX] smtpLogin-fix (22 November 2002) * m rueger (22 November 2002) > http://swiki.gsug.org:8080/sqfixes/2808.html This is a fix to mirs network rewrite. So it's not currently applicable. Speaking of which, I would like to know how that is doing. I've been testing the SMTP stuff since it was released, and have no complaints to it, so maybe it's time to start integrating it. I don't want to wait until it's all done. > [ENH] system category cleanup in 3.4a (20 November 2002) * Anthony > Hannan (20 November 2002) > http://swiki.gsug.org:8080/sqfixes/2788.html > - Preamble claims this was requested by Scott Wallace. :-) already in as 5112. > [BUG][FIX] BitEditor>>setColor: (18 November 2002) * Brian T Rice (18 > November 2002) > http://swiki.gsug.org:8080/sqfixes/2781.html In as 5116. Daniel Vainsencher

3 2

Re: [Squeakfoundation]base image distribution
by Daniel Vainsencher 09 Dec '02

09 Dec '02

The directions you are talking about are not theoretical, that's where it's going. In order for the process to work though, we have to work within some constraints: 1. People contribute to Squeak because they can run it and play with it, and modify it, and on it, they also get all this cool Stuff. Therefore, SqueakMap comes before any stripping. StableSqueak ignored this constraint, and that alone was a big risk. We're past that step. 2. People want to run some complicated things that require lots of infrastructure, like Celeste (HTML, networking, MailMessage, Morphic, FileSystem...). We are not the Forth crowd, where users are happy if they get multiplication of Floats in the library (just kidding!). Therefore, no serious stripping before we get some working mechanism for distributions/configurations. 3. While we work to make Squeak more malleable to more people, we need to make sure we don't turn it into putty nobody can build anything on. If there is no mail client in Squeak, just in SM, that's fine. If there's no one socket api to work against, we have a serious problem. Stephen, I think people starting to build their own images from base + packages could be a great accelerator for all the reasons you mention. After we get configurations, this work will be easily sharable, too. Do you want to try it out and publish your process so people can repeat it and improve on it? Daniel Rob Withers <rwithers12(a)attbi.com> wrote: > I completely agree, almost. :) What is the smallest feature set for the > base stripped image? Is there a swiki page on this? > cheers, > rob And > From: "Stephen Pair" <spair(a)acm.org> > Indeed, I'd take it a step further and say no new features period...ever > (for the base Squeak that is). Stuff like a new events mechanism, > networking frameworks, etc...should all remain as external packages. We > need to be working in that opposite direction and start having change > sets in the update stream jettison code, not add. > > Now, what would be great is to have a base Squeak realease, plus a > number of "distributions" that contain a variety of packages that are > pre-loaded. One of these could be the SqC distribution that is > downloadable from the squeak.org site (this would be the distro that > most people download first). > > One of the things that could be done to help encourage progress in that > direction is to start thinking about automating image construction > (i.e., take the base image, add packages X, Y, and Z, then publish > somewhere). Some tools to help with that would be nice. > > - Stephen > Stephen Pair <spair(a)acm.org> wrote: > What I would suggest (and I'm probably going to start doing this at some > point in the future myself) is that you (and others) start publishing > your own Squeak image...and do it through an automated nightly job that > pull the updates off the stream, collects all of the packages that you > want in the image, runs any Sunits, etc. > > This will be useful in a number of ways: > > a) it will serve you by having an image readily available with > exactly the things you want in it > b) it will serve the community by making that available > c) it will keep you disciplined in the sense that any changes > you want included in your base image will be factored out and separately > loadable > d) it will serve the community because it will be exercising a > lot of code (and probably Sunits) on a daily basis (if anything breaks > in your build, we'll all know right away) > e) it will serve you because if anything does break your build, > you can point to exactly what change caused it to break, alert the > people involved, and get them to change their code to accommodate your > build > > The thing missing here is the automated part...but that can come with > time. > > - Stephen

2 1

Re: [Squeakfoundation]Ad-hoc final harvesting for 3.4
by Daniel Vainsencher 09 Dec '02

09 Dec '02

I agree. Fixing the existing events system is a reasonable goal for 3.4, a new one might be for 3.5. Daniel Ned Konz <ned(a)bike-nomad.com> wrote: > On Sunday 08 December 2002 11:35 am, Andreas Raab wrote: > > The problem is that #click is really a trigger for a method > > (script) in the window which may happen asynchronously. And this > > script is clearly owned by the window and not by the button and > > that's what all of these event frameworks never take into account. > > With the model that I built this is different (and not only in this > > respect ;-) Here, the subscriber always remembers its registrations > > (messages) *strongly* and the publisher always remembers the > > subscriptions *weakly* (by default). > > This sounds like a good scheme. Perhaps in 3.5? > > -- > Ned Konz > http://bike-nomad.com > GPG key ID: BEEA7EFE > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

[ANN] IvapParser (on SqueakMap)
by Daniel Vainsencher 07 Dec '02

07 Dec '02

Hi everybody. Stephen Pair <spair(a)acm.org> wrote: > P.P.S. What about putting this into the base Squeak (or rather the > compiler package)? Guides? In scope, it relates to the compiler, which is appropriately in the base. It traps reads and writes even when code attempts to directly access a variable. It allows interesting reflective tricks like Kats and Seaside depend on, which might be useful in other contexts as well (GemStone does the same thing, probably the GemStone client would be simpler with this modification). I think this is an interesting case for various reasons: 1. It allows an interesting class of applications and extensions to the system. 2. It complicates the base system somewhat - both in code and in semantics (this issue also interacts with whether Stephen uses subclassing or modification of the base). 3. It is already tested, but only by it's author. What do people think? Daniel

1 0

LinesInHierWIcon-nk
by Daniel Vainsencher 07 Dec '02

07 Dec '02

I think scope wise (no opinion on quality, haven't looked), both of the mentioned improvements should get into the image. Our list and hierarchial widgets should be as good as we can make them. This doesn't prevent them being maintained as SM packages in the near future, if someone is interested. What do you guys think? Daniel Ned Konz <ned(a)bike-nomad.com> wrote: > > --Boundary_(ID_czyeJfrbgndEldvMifen+Q) > Content-type: TEXT/PLAIN > Content-transfer-encoding: 7BIT > > from preamble: > > "Change Set: LinesInHierWIcon-nk > Date: 5 December 2002 > Author: Ned Konz > > This is a minor mod to Steve Swerlings linesInHierarchy change set that > will work better with my HierListsWithIcon-nk changeset. It does not > affect the functioning of his changeset. > "! > > --Boundary_(ID_czyeJfrbgndEldvMifen+Q) > Content-type: application/octet-stream; NAME=LinesInHierWIcon-nk.cs.gz > Content-transfer-encoding: base64 > Content-disposition: attachment; filename=LinesInHierWIcon-nk.cs.gz > > H4sIAAAAAAAAANWWXW/aMBSGr3Ph/3BgF9lUlTZQ1ilX3ajQ0LpOGkjdVLXIJA6xmtgsNqVM > /fE7TkxIUvp10YtJCEzO53v82Io7zGQK4z9LRm96naMZ0xRkBK7rwSkLWDpjGXQPD7uuC5cJ > 1UxpWC5CXPjwru/1Pl2BFNCv+wLV0PO7Pf+oD4vUbZH2IKZizmDMtO84Z1wwNRJfOcsuRoEU > ++KGnJqMjuM0MpHPSx3LzFjOWQjfpPhLyCTmCvBDIeVCZpDKELSEsWa3WGLFsoSLuYJkW4Zm > QbyGoGhCMQ06xhZXPElgJbMbQNUaK664jiFdgwk540qrC3xgO7TRGNyBkYZQMgVCaqBRxAKT > kEG0FIHmUmB1M0LT5TaItFuEkNZIhExo9DD5R5ql32W2wKIMZYZqiFLBDTO6Qg8XlKbpAh9g > da970D/IZ+v1fe8YZ2q8zCQncj5P8HvC7vQP4QMdUHFLC/kDmZiM5ZIQ5x4FfpFLESpcDLAX > 1B2bPL+LnzMWaYB79Cz9pjiyJMIRm0L2WcfYbfh0mzLIn3Qw2uacbqusYR88Y8qzxVQVnQOP > JtmS+ZfEcbYdVHJmfB5rjO1izSv0HtJEIX0P/W2du6KOc2VqtU9xTPkAIDKgFyIMLhrn1SbO > ZlyYzTFuPrwvs54UIj7kRi3R1OxqDw5h42WcVjzUsQ+eWQeN4WM7CAC03oQCHOaQZ0oPYp6E > z2NQoQBuTfwv+zuRi2LxRWqN80KCMeFmd83aTvl+s5FRWRbP5DlPyv2E69yeb0OTpVlJUTW/ > NVYyNpmrdjCt91aSZ/VModbvnSWoVFkhbJZr7exQtJPS6nymtSIG8eMaps/4P4ZpmiMqEFFQ > fGbus92oWq0nG1VVVGu2ovxLGH1DQs9Rz7iQ8ypERRFn/1ld5Xm3VvtvN8UlrWLbwuO4Pn33 > 4Z7VG7I+1dSvuSuduoBpQ+4usGt3XffpO7UGfMnpHvQfXqc7XTeIPtD4grNRV/aS09GIsMX/ > 0wOCrazxZQNfCxKqFI84C584LB/xsFS5Ic51hb2f+JaB7xIJy8v/Az5alDi2CQAA > > --Boundary_(ID_czyeJfrbgndEldvMifen+Q)--

3 2

Re: [FIX] MVC in one bit mode
by Doug Way 05 Dec '02

05 Dec '02

Okay, I've tested this one and I'd recommend including it. It fixes a definite display problem which shows itself whenever you scroll a pane in 1-bit mode in MVC. The fix itself includes a check for 1-bit mode, and is in MVC-related code, so it seems pretty safe that it won't affect anything else. (Perhaps there is a more direct fix which could be made to bitBlt or somewhere else, I'm not sure, but this fix seems simple & direct enough.) - Doug Bruce ONeel wrote: > > MVC is broken in one bit mode. The fix is below. > > -------------------------------------------- > Name: oneBitMVC.2.cs > oneBitMVC.2.cs Type: ChangeSet (application/x-unknown-content-type-cs_auto_file) > Encoding: BASE64

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation December 2002