(restartAlsoProceeds true)
I suggest that this should be off by default. When it is off, you can easily proceed by issing a cmd-P, but when it is on, you cannot obtain the opposite effect. It is also more helpful to beginners not to immediately proceed. Currently it is "true" because that is how it used to be when this improvement didin't exist, and I don't think that is a higher priority.
(alternativeScrollbarLook true)
(roundedMenuCorners true) (roundedWindowCorners true)
I suggest that all of these should have the effect of setting rounded corners not to be used. It is far from obvious to beginners that these hog a lot of performance. On the other hand, the added value of having rounded corners is--well I just don't know any but there has to be something I'm sure.
I assume that Doug's menu improvements have gone in, I haven't used 3.2g in a while.
Henrik
At 12:20 PM +0100 4/19/02, Henrik Gedenryd wrote:
(restartAlsoProceeds true)
I suggest that this should be off by default. When it is off, you can easily proceed by issing a cmd-P, but when it is on, you cannot obtain the opposite effect. It is also more helpful to beginners not to immediately proceed. Currently it is "true" because that is how it used to be when this improvement didin't exist, and I don't think that is a higher priority.
Ah, good point. I agree. RestartAlsoProceeds should be 'false' by default.
-Martin
I suppose I agree, reluctantly, with Henrik's position about rounded corners, and would be inclined to change the out-of-box look of 3.2 accordingly.
Opinions?
-- Scott
At 12:20 PM +0100 4/19/02, Henrik Gedenryd wrote:
(roundedMenuCorners true) (roundedWindowCorners true)
I suggest that all of these should have the effect of setting rounded corners not to be used. It is far from obvious to beginners that these hog a lot of performance. On the other hand, the added value of having rounded corners is--well I just don't know any but there has to be something I'm sure.
Scott,
Must have missed this message:
I suppose I agree, reluctantly, with Henrik's position about rounded corners, and would be inclined to change the out-of-box look of 3.2 accordingly.
Opinions?
Yes. I strongly disagree. If the argument is that it eats to many cycles, perhaps it would be useful to see _where_ these cycles go. With the recent changes there are many more rounded corners on the screen than ever before (all the optional buttons) and it seems silly to me to turn corner rounding on windows off "because it's slow". Let's look at the problem (speed) rather than the symptom (rounded corners).
Cheers, - Andreas
Andreas Raab wrote:
Yes. I strongly disagree. If the argument is that it eats to many cycles, perhaps it would be useful to see _where_ these cycles go. With the recent changes there are many more rounded corners on the screen than ever before (all the optional buttons) and it seems silly to me to turn corner rounding on windows off "because it's slow". Let's look at the problem (speed) rather than the symptom (rounded corners).
This is a pseudo-logical argument. They are not the symptom. They are the cause. The symptom is slowness. Silliness lies in insisting that they be on without stating what their advantage is.
We all may have opinions about the aesthetics of the rounded corners, but turning them off was concluded on a purely rational basis.
So what is the rational argument for keeping rounded courners on? I.e. what do they improve? If there is some purpose, then this can be traded against the loss in speed. But unless the advantages of rounded corners aren't stated then I can't really see an argument.
The argument for having rounding on at all in the first place should really have nothing to do with speed. But a speed problem would add more weight against them.
Henrik
Henrik,
This is a pseudo-logical argument. They are not the symptom. They are the cause. The symptom is slowness.
I'm sorry but this is plain nonsense. If you would have ever looked at the current inefficiencies of Morphic drawing operations then you would understand that rounded corners on windows and menus just expose these inefficiencies. Three examples:
#1: The "areasRemaingToFill" are way larger than they need to be for rounded corners.
#2: The top-down drawing method of the world is broken. It has tons of overdraw which could be completely eliminated.
#3: CornerRounder does its work even if some of the rounded corners are completely invisible.
All of the above are particularly bad for overlapping windows since #1 requires (possibly large) regions to be redrawn[*1], #2 means that complex objects need are drawn multiple times] and #3 means that stacked arrangements will pay a much larger price than those that are side by side. Fixing all of the above would make drawing in general faster and fix the apparent slowdown for rounded corners on menus and windows as a side effect.
[*1] Notice that for overlapping windows which are usually more wide than tall the logic in CornerRounder>>rectWithinCorners: is exactly wrong since it returns the larger portion of the rectangle. And in those places where the logic is used (namely areasRemainingToFill) the returned areas should be as small as possible.
Incidentally, I am still waiting for numbers on the subject. Can somebody provide some test cases so we can see what the actual slowdown is like?!
Silliness lies in insisting that they be on without stating what their advantage is.
You didn't get what I was saying: I said it's silly to turn rounding corners off "because it's slow" when - at the same time - we add tons of optional buttons which all have rounded corners. In other words: We trade four rounded corners on a system browser against 32 on the optional button pane. And that _does_ seem a bit silly, doesn't it?!
We all may have opinions about the aesthetics of the rounded corners, but turning them off was concluded on a purely rational basis.
For your own sake, I hope you don't mean what you're implying above. Is it now the case that user experience is judged exlusively on "rational" arguments?! If so, then I'll concede and find a bunch of people who are more in for the fun of it. I can understand Stephane's message (even though I disagree) but claiming that user experience is exclusively determined by rational arguments seems ... a bit silly.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Henrik Gedenryd Sent: Wednesday, May 01, 2002 4:46 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: rounded corners (was: Re: straw-man 3.2 default preferences)
Andreas Raab wrote:
Yes. I strongly disagree. If the argument is that it eats to many cycles, perhaps it would be useful to see _where_ these
cycles go. With
the recent changes there are many more rounded corners on the screen than ever before (all the optional buttons) and it seems
silly to me to
turn corner rounding on windows off "because it's slow".
Let's look at
the problem (speed) rather than the symptom (rounded corners).
This is a pseudo-logical argument. They are not the symptom. They are the cause. The symptom is slowness. Silliness lies in insisting that they be on without stating what their advantage is.
We all may have opinions about the aesthetics of the rounded corners, but turning them off was concluded on a purely rational basis.
So what is the rational argument for keeping rounded courners on? I.e. what do they improve? If there is some purpose, then this can be traded against the loss in speed. But unless the advantages of rounded corners aren't stated then I can't really see an argument.
The argument for having rounding on at all in the first place should really have nothing to do with speed. But a speed problem would add more weight against them.
Henrik
I love the rounded corners. Heck, I even wrote a goodie that makes the drag outline have rounded corners when you move a window. It's a neat touch.
Andreas makes an excellent point showing that we have many other rounded features in our environment.
And I think we should address the performance hit. Although I suspect several, if not many, folks have ever noticed it.
We should create the environment we want and then go back and see where it hurts if necessary. For slow machines turn it off manually. Shouldn't we keep our eye on where we want to go and continue to allow for the fact that the machines we use get faster? We could identify "performance heavy" options in the preferences and perhaps even note them in the read me.
As far as 3.2gamma is concerned, trying to engineer something clever to fix the performance of round corners is not a good idea. We're too close to the finish line. Let's address it in a later release.
While I'm ranting a bit, isn't it always smarter to show someone what you are trying to accomplish with the GUI soon and then go back and address the performance? Think about it this way. I remember when first trying Morphic back when it was new. And man was it slow on my machine. I stuck with it. The machines are faster and Morphic has also improved (I think) in performance. I don¹t think too often about starting an MVC project anymore.
End of rant. :)
- Steve
Stephan,
Just a minor note:
And I think we should address the performance hit. Although I suspect several, if not many, folks have ever noticed it.
I actually believe that almost all of the *felt* slowdown of rounded corners is fixed these days. It used to be the case that dragging an object with rounded corners around was significantly slower than dragging one without rounded corners (e.g., menus or windows) which makes the system feel a lot slower. This problem has been addressed (by a trick of yours truly, heh, heh ;) which makes dragging an object with rounded corners almost as fast as one without 'em (within a 10% range where it used to be a factor of two).
That's why I was asking for numbers in my previous postings ;)
Cheers, - Andreas
I believe it.
It's like I was saying, Morphic itself used to feel pretty slow years ago and now it's just fine. The rounded corners stuff doesn't seem to be an issue for many folks and it's a nice looking feature.
I'd rather have the quality look we can generate for Squeak and resolve performance issues as they come up.
- Steve
On 5/2/02 1:10 PM, "Andreas Raab" Andreas.Raab@gmx.de wrote:
Stephan,
Just a minor note:
And I think we should address the performance hit. Although I suspect several, if not many, folks have ever noticed it.
I actually believe that almost all of the *felt* slowdown of rounded corners is fixed these days. It used to be the case that dragging an object with rounded corners around was significantly slower than dragging one without rounded corners (e.g., menus or windows) which makes the system feel a lot slower. This problem has been addressed (by a trick of yours truly, heh, heh ;) which makes dragging an object with rounded corners almost as fast as one without 'em (within a 10% range where it used to be a factor of two).
That's why I was asking for numbers in my previous postings ;)
Cheers,
- Andreas
I am trying to show a collection of forms at a set rate. I came up with this:
formCollection do: [:aForm| aForm display. (Delay forSeconds: (1/30)) wait.].
the problem is that it is skipping many frames and getting about 3-4 fps instead of the 30 is should be.
I'm thinking it is getting put in a buffer to be displayed the next time the screen gets updated..and that is just gitting overwritten b/w updates.
Is there any way to force it to write imediately? Lushi
o |Yisrael Lowenstein: Computer Science Master's Student & Squeaker () o|lushi@bigfoot.com; gte356h@prism.gatech.edu; lushi@cc.gatech.edu o_/||/ |"Before you criticize a man, walk a mile in his shoes. That way || | when you do criticize him, you'll be a mile away and have his _/_ | shoes." - Unknown AIM: YisraelL ICQ: 1037061 Class Schedule: http://www.prism.gatech.edu/~gte356h/schedule/
Yisrael Lowenstein wrote:
I am trying to show a collection of forms at a set rate. I came up with this:
formCollection do: [:aForm| aForm display. (Delay forSeconds: (1/30)) wait.].
the problem is that it is skipping many frames and getting about 3-4 fps instead of the 30 is should be.
I'm thinking it is getting put in a buffer to be displayed the next time the screen gets updated..and that is just gitting overwritten b/w updates.
Is there any way to force it to write imediately? Lushi
Look at the class DisplayObject. 30 fps can bring Squeak to it's knees if the images are big.
Karl
30 fps can bring Squeak to it's knees if the images are big.
The images are small, and I don't need to refresh the whole screen..just that part of it...
How does the mpeg player do it?
Might the problem be that the Delay is keeping it from being refreshed? is there a different way to delay or to just make the delay delay in the block, and not the whole system? does fork do this?
Lushi
o |Yisrael Lowenstein: Computer Science Master's Student & Squeaker () o|lushi@bigfoot.com; gte356h@prism.gatech.edu; lushi@cc.gatech.edu o_/||/ |"Before you criticize a man, walk a mile in his shoes. That way || | when you do criticize him, you'll be a mile away and have his _/_ | shoes." - Unknown AIM: YisraelL ICQ: 1037061 Class Schedule: http://www.prism.gatech.edu/~gte356h/schedule/
Yisrael Lowenstein wrote:
30 fps can bring Squeak to it's knees if the images are big.
The images are small, and I don't need to refresh the whole screen..just that part of it...
How does the mpeg player do it?
The mpeg player has a mpeg display morph that sends a self changed message and a
drawOn: aCanvas aCanvas drawImage: frameBuffer at: bounds origin
method
Karl
Might the problem be that the Delay is keeping it from being refreshed? is there a different way to delay or to just make the delay delay in the block, and not the whole system? does fork do this?
Lushio |Yisrael Lowenstein: Computer Science Master's Student & Squeaker () o|lushi@bigfoot.com; gte356h@prism.gatech.edu; lushi@cc.gatech.edu o_/||/ |"Before you criticize a man, walk a mile in his shoes. That way || | when you do criticize him, you'll be a mile away and have his _/_ | shoes." - Unknown AIM: YisraelL ICQ: 1037061 Class Schedule: http://www.prism.gatech.edu/~gte356h/schedule/
Use:
Display forceToScreen: aForm boundingBox.
inbetween your frames.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Yisrael Lowenstein Sent: Thursday, May 02, 2002 7:39 PM To: squeak-dev@lists.squeakfoundation.org Cc: squeakers@cc.gatech.edu Subject: displaying forms rapidly without skipping frames.
I am trying to show a collection of forms at a set rate. I came up with this:
formCollection do: [:aForm| aForm display. (Delay forSeconds: (1/30)) wait.].
the problem is that it is skipping many frames and getting about 3-4 fps instead of the 30 is should be.
I'm thinking it is getting put in a buffer to be displayed the next time the screen gets updated..and that is just gitting overwritten b/w updates.
Is there any way to force it to write imediately? Lushi
o |Yisrael Lowenstein: Computer Science Master's Student & Squeaker () o|lushi@bigfoot.com; gte356h@prism.gatech.edu; lushi@cc.gatech.edu o_/||/ |"Before you criticize a man, walk a mile in his shoes. That way || | when you do criticize him, you'll be a mile away and have his _/_ | shoes." - Unknown AIM: YisraelL ICQ: 1037061 Class Schedule: http://www.prism.gatech.edu/~gte356h/schedule/
I am trying to show a collection of forms at a set rate. I came up with this:
formCollection do: [:aForm| aForm display. (Delay forSeconds: (1/30)) wait.].
the problem is that it is skipping many frames and getting about 3-4 fps instead of the 30 is should be.
See my note 3/11/02 [BUG] why is frame rate in 3.2.5 slower & the followon note towards an accurate delay....
The thing that might not be apparent is that you are asking to have Squeak sleep your process for 1/30 of second. However when your process will run again is dependent on what else is going on. So think of it as 1/30 sec + overrun error in the VM 0-16ms? + time taken for another higher priority process to complete or a process switch to occur.
In the orginal mpeg player the logic which is smalltalk accessible code btw would look at how many frames into the movie, versus the clock time and adjust how long to wait. For what you are doing you want to consider how long it is taking between calls to your delay routine and adjust things so that you are being called every 1/30 of second.
Mind if you can't do > 30 frames a second with no delay the effort is useless, however you might still need the code when Squeak and the machine become 10x faster in the next N years.
You could always make a Morpic and rely on the step logic, which still in my opinion needs the fix mentioned above in [BUG] why is frame rate in 3.2.5 slower.
Andreas,
#2: The top-down drawing method of the world is broken. It has tons of overdraw which could be completely eliminated.
Is there some straightforward way to do this, or is it tangled everywhere in the code? As a ballpark estimate, what type of speed increase do you think would come out of working in this area?
Jim
Jim,
If you can understand WorldState>>drawWorld:submorphs:invalidAreasOn: then it's probably straightforward. But don't ask me ... I don't get a thing in there. I actually believe it's worthwhile to rethink the entire drawing strategy in the light of having many small portions which need to be redrawn. The drawing strategy as implemented in the method appears to work well for strictly rectangular areas where #areasRemainingToFill: returns either "all-or-nothing".
Considering a different redrawing strategy, I would go for an approach where see morphs as "layers" rather than morphs, e.g., just assume that we have a bunch of layers that should be restored in top-down order. Then, we have to traverse all layers and on our way down we wish to eliminate all the portion of the pending damage regions that are known to be restored by the current layer (morph) and pass the remaining remaining damage to the next layer below. Once we're at the bottom, we draw the world's background in the damage regions. On our way up, we draw each layer with the damage rectangles that were passed in by the sender. Simple eh?! ;-)
Issues to consider: * The damage passed in should be filtered at each layer to only redraw those damage regions that overlap with the morphs full bounds * Layers should be skipped quickly if no damage area overlaps the morph at this layer (e.g., having a bunch of morphs in "front" but outside a damage region should have a shortcut) * Redrawing morphs with a LIST of damage rects could _heavily_ improve performance. The damage rects would need to applied at the "primitve" level, e.g., GrafPort might be able to handle the operations. For the general case it could be implemented by just drawing the entire morph repeatedly. [Side note: this should also improve Nebraska performance since the damage rectangles would be transmitted once as well as the drawing operations]. * The top-down drawing method should be implemented in class Morph so it's accessible for all morphs which want to implemented #fullDrawOn: by using the top-down drawing strategy (WorldState's method is nothing but a different way to implement #fullDrawOn: - and there is absolutely nothing World specific about it)
How much to expect from such a change?! Hard to say exactly (I'm still waiting for test cases that show the slowdown for rounded corners). However, overdraw being one of the major slowdowns in computer graphics I guess its reasonable to expect the slowdown for (at least) the case of rounded corners to be virtually unnoticable. A good test case might be to use an arrangement of RectangleMorphs which mimick overlapping windows and have various operations (moving, resizing, invalidating) occur on random elements.
Ah, yes, and here's a neat little trick if you want to work on it: When you are trying to implement such a crucial method you should * duplicate the #drawWorld:... as #drawWorld2:... * add a line in #drawWorld:... saying self doOnlyOnce:[^self drawWorld2: ...]. * as the last line of #drawWorld2:... add self rearmOneShot. Thus the new version will have to complete in order to be called again. If it raises an error it'll just fall back to the old version and needs to be manually reinstanted. I find this trick to be tremendously useful when you have to work on those kind of problems.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Jim Benson Sent: Wednesday, May 01, 2002 9:16 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: rounded corners (was: Re: straw-man 3.2 default preferences)
Andreas,
#2: The top-down drawing method of the world is broken. It
has tons of
overdraw which could be completely eliminated.
Is there some straightforward way to do this, or is it tangled everywhere in the code? As a ballpark estimate, what type of speed increase do you think would come out of working in this area?
Jim
Jim and all,
After I outlined the way how to eliminate the overdraw I couldn't withstand finding a good benchmark. Finally, I came across one which simply opens a bunch of browsers and measures the time to activate them all around. It's a typical one since that's what you do all along when you switch between different tools. And guess what... the benchmark (see prefix of the CS) showed that with square corners activating system windows is more than two times faster than with rounded corners. Implementing the overdraw-eliminating strategy alone brings this down to roughly 40% overhead. So much for accurately determining dirty regions.
Adding a tweak here and there including making the visibility tests in Canvas _accurate_, removing various sends of #isKindOf: from a couple of methods in Rectangle, and finally adding a single specific optimization for rounded corners to BorderedMorph>>areasRemainingToFill: brings this down to 15%.
Not bad, eh?! I'm sure there are more speedups hidden (there alway are ;-) For example, I didn't bother to check for visibility of individual rounded corners in CornerRounder since most of these seem to be removed already by the - now accurate - visibility tests in Canvas. Also, I didn't do anything about handling damage groups although the hooks are in place now. I'm pretty certain that you can get the overhead into the 5% range but I don't really care at this point ;-)
Here are some numbers from the activation benchmark: Square Corners: 3585ms Rounded Corners: 7531ms (before tweaks), ratio 2.10 Rounded Corners: 4095ms (after tweaks), ratio 1.14
Cheers, - Andreas
But, Henrik, what is the "rational argument" for having color or even gray scale or different fonts in the developer interface or any interface? Or flowers on your desk? Part of UI is ambience.... If you don't like rounded corners, then you should be able to turn them off, etc.
Cheers,
Alan
-------
At 4:45 PM +0200 5/1/02, Henrik Gedenryd wrote:
Andreas Raab wrote:
Yes. I strongly disagree. If the argument is that it eats to many cycles, perhaps it would be useful to see _where_ these cycles go. With the recent changes there are many more rounded corners on the screen than ever before (all the optional buttons) and it seems silly to me to turn corner rounding on windows off "because it's slow". Let's look at the problem (speed) rather than the symptom (rounded corners).
This is a pseudo-logical argument. They are not the symptom. They are the cause. The symptom is slowness. Silliness lies in insisting that they be on without stating what their advantage is.
We all may have opinions about the aesthetics of the rounded corners, but turning them off was concluded on a purely rational basis.
So what is the rational argument for keeping rounded courners on? I.e. what do they improve? If there is some purpose, then this can be traded against the loss in speed. But unless the advantages of rounded corners aren't stated then I can't really see an argument.
The argument for having rounding on at all in the first place should really have nothing to do with speed. But a speed problem would add more weight against them.
Henrik
--
Alan Kay wrote:
But, Henrik, what is the "rational argument" for having color or even gray scale or different fonts in the developer interface or any interface? Or flowers on your desk? Part of UI is ambience.... If you don't like rounded corners, then you should be able to turn them off, etc.
Cheers,
You are clearly talking about aesthetics. But when I taught graphic design for user interfaces, rounded corners was not part of any principle or textbook I ever saw. The basic rule is "form follows function" even if that is somewhat simplified. You are absolutely right that gratuitous color and so on are redundant and that's basically what is taught. This is why multi-colored windows are also well known to be bad design (not to mention colored window pane backgrounds!). And so on. They like rounded corners on windows and menus are gratuitous decoration.
When I buy a desk, it doesn't come with garish flowers that I can turn off if I don't like them. You *add* these things if that's what you like. The basic options are simple and clean, and if you want to clutter things up then you may do so.
But to think that user experience is about "whatever you like" or arbitrary choices is completely wrong. Many people think that UI is just a matter of opinion, and last week Don Norman said that when he coined the term "user experience" he didn't have in mind what people mean by it now. He would have a field day with the sausage scrollbars btw.
There are well established principles for good graphic communication. What else would they teach in graphic design? "Dream up an ambience that you like"? Good books in this area are actually pretty hard to find. The book by Mullet & Sano is the best one out there, at least for computer-related things. I really recommend it.
There was a guy on the list a month or so ago that clearly knew graphic design and offered help, and the first thing he suggested that New York be replaced, which is an obvious point since it is well known that sans serif typefaces are the best choice for cases like Squeak.
You are right in that Squeak does have an "ambience". And for anyone with graphic design training (etc.) who know how to "read" such things, Squeak's ambience reads "amateurism". There have been several people who know these things who have offered help. But Squeak will probably always be ruled by the programmer's aesthetic.
Henrik
But Squeak will probably always be ruled by the programmer's aesthetic.
Henrik
That sounds like a reasonable paraphrase of some of Smalltalk's founding principles. Bearing in mind that Smalltalk was introduced as a means to make every end user the programmer, Squeak once again proves itself the purest current expression of those principles.
Gary
On Fri, 3 May 2002, Henrik Gedenryd wrote:
Alan Kay wrote:
But, Henrik, what is the "rational argument" for having color or even gray scale or different fonts in the developer interface or any interface? Or flowers on your desk? Part of UI is ambience.... If you don't like rounded corners, then you should be able to turn them off, etc.
You are clearly talking about aesthetics.
Exactly.
[...]
You are right in that Squeak does have an "ambience". And for anyone with graphic design training (etc.) who know how to "read" such things, Squeak's ambience reads "amateurism". There have been several people who know these things who have offered help. But Squeak will probably always be ruled by the programmer's aesthetic.
Rectangular windows are the result of "programmer's aesthetic". It's the most straight-forward thing to do. Adding roundness makes the interface just a tad friendlier.
Regarding "amateurism" in the context of rounded windows (I agree that most other visual aspects of Squeak's GUI are at best "amateurish"): The two most recent major GUIs both have rounded window corners. I'm sure they pay a lot for professional designers. On a related note, Macs have had rounded screen corners for ages, but surely not for any usability reason.
-- Bert
Bert Freudenberg wrote:
Adding roundness makes the interface just a tad friendlier.
I disagree. Adding roundness makes the interface, well, "round"-- that's all. I think it's all just a matter of what you are used to.
The two most recent major GUIs both have rounded window corners.
Which means users from those platforms will be used to rounded window corners, and hence will (probably) prefer rounded window corners for the simple reason that that is what they are used to. I personally prefer square window corners, again because it is what I am used to. So, I think it's good that Squeak supports it both ways.
But I still think that it's just a matter of what you are used to.
Nevin
At 1:59 AM -0700 4/30/02, Scott Wallace wrote:
I suppose I agree, reluctantly, with Henrik's position about rounded corners, and would be inclined to change the out-of-box look of 3.2 accordingly.
Opinions?
An opinion, but not a strong one:
I have not noticed a performance problem with rounded corners (and I haven't timed how much time they consume), but I have been running with square corners for a while. I find the square corners a bit nicer-looking, and I find it easier to visually distinguish windows from buttons and flaps when some are square and some are rounded than when all are rounded.
-Martin
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Bert Freudenberg -
Gary Fisher -
Henrik Gedenryd -
Jim Benson -
John M McIntosh -
Karl Ramberg -
Martin McClure -
Nevin Pratt -
Scott Wallace -
Stephan B. Wessels -
Yisrael Lowenstein