"Change Set: PLMCleanUpStart Date: 9 August 2003 Author: Daniel Vainsencher
This changeset adds comments for all PLM subclasses.
Also removes the assumption of uniform height in PluggableListMorph (not yet in subclasses), and refactors the morph generation. Might slow list update down a bit.
Factors out the StringMorph creation and initialization logic to simplify the methods and reduce duplication.
The goal is to introduce the ability to accept items other than String/Text/MethodReference, and display them as morphs other than StringMorphs.
Patches/advice about how to handle PLM variants welcome."!
Changeset looks good so far.
While we're looking at this area, here's a suggestion. Can we get rid of the resizing of every morph to be 9999 wide? Other than being ugly, there could be problems if we actually start using list items other than StringMorphs - they may not appreciate being resized grossly. It will also make list initializing a touch faster.
Attached is a first shot at doing so - its meant to go on top of Daniel's changeset, not the in-image version, though it could be done there, too.
Eddie
----- Original Message ----- From: "Daniel Vainsencher" danielv@netvision.net.il To: squeak-dev@lists.squeakfoundation.org Sent: Saturday, August 09, 2003 10:28 AM Subject: [ENH][Refactor] PLMCleanUpStart
"Change Set: PLMCleanUpStart Date: 9 August 2003 Author: Daniel Vainsencher
This changeset adds comments for all PLM subclasses.
Also removes the assumption of uniform height in PluggableListMorph (not yet in subclasses), and refactors the morph generation. Might slow list update down a bit.
Factors out the StringMorph creation and initialization logic to simplify the methods and reduce duplication.
The goal is to introduce the ability to accept items other than String/Text/MethodReference, and display them as morphs other than StringMorphs.
Patches/advice about how to handle PLM variants welcome."!
---------------------------------------------------------------------------- ----
While we're looking at this area, here's a suggestion. Can we get rid of the resizing of every morph to be 9999 wide?
The reason for this is mostly to avoid (potentially expensive) resizing of StringMorphs when you resize a PLM. In other words, with your changes (which I haven't tried) it is likely that you have to click exactly on the string and not "to the right" before the string ends. While I don't consider the current solution to be very nice, the UI problems that your solution introduces seem much worse to me.
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
While we're looking at this area, here's a suggestion. Can we get rid of the resizing of every morph to be 9999 wide?
The reason for this is mostly to avoid (potentially expensive) resizing of StringMorphs when you resize a PLM. In other words, with your changes (which I haven't tried) it is likely that you have to click exactly on the string and not "to the right" before the string ends. While I don't consider the current solution to be very nice, the UI problems that your solution introduces seem much worse to me.
Surely the maximum practical size that is relevant is the Display width? Actually I guess it is really (Display width - morph left) but plain Display width would probably do.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: EFBI: Emulate Five-volt Battery Intermittently
On Saturday 09 August 2003 04:54 pm, Tim Rowledge wrote:
"Andreas Raab" andreas.raab@gmx.de wrote:
While we're looking at this area, here's a suggestion. Can we get rid of the resizing of every morph to be 9999 wide?
The reason for this is mostly to avoid (potentially expensive) resizing of StringMorphs when you resize a PLM. In other words, with your changes (which I haven't tried) it is likely that you have to click exactly on the string and not "to the right" before the string ends. While I don't consider the current solution to be very nice, the UI problems that your solution introduces seem much worse to me.
Surely the maximum practical size that is relevant is the Display width? Actually I guess it is really (Display width - morph left) but plain Display width would probably do.
Until you change the window or screen size.
Ned Konz ned@bike-nomad.com wrote:
On Saturday 09 August 2003 04:54 pm, Tim Rowledge wrote:
Surely the maximum practical size that is relevant is the Display width? Actually I guess it is really (Display width - morph left) but plain Display width would probably do.
Until you change the window or screen size.
Sure, but why is that an issue? IIRC Andreas made the point that one wouldn't want to resize these morphs all the time, which leads me to believe that they can be resized. Assuming that this is true, what would be wrong with resizing them on the rare occasions that the Display is resized? After all a pretty big redraw is done then anyway. I'm not particularly invested in any of this but it does seem like keeping the morph size realistic might be a help is reducing the excessive redrawing that is claimed to be part of the morphic performance drain. And that is something I'd really like to see improved.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: TOAC: Turn Off Air Conditioner
What's the benefit in adjusting the width to the screen width, anyway? When I get a halo on a StringMorph in a list, it will still annoyingly go all the way to the right side of the screen whether its width is 1280 or 9999. No extra drawing is done with a width of 9999. Etc.
Joshua
On Sun, Aug 10, 2003 at 09:12:32PM -0700, Tim Rowledge wrote:
Ned Konz ned@bike-nomad.com wrote:
On Saturday 09 August 2003 04:54 pm, Tim Rowledge wrote:
Surely the maximum practical size that is relevant is the Display width? Actually I guess it is really (Display width - morph left) but plain Display width would probably do.
Until you change the window or screen size.
Sure, but why is that an issue? IIRC Andreas made the point that one wouldn't want to resize these morphs all the time, which leads me to believe that they can be resized. Assuming that this is true, what would be wrong with resizing them on the rare occasions that the Display is resized? After all a pretty big redraw is done then anyway. I'm not particularly invested in any of this but it does seem like keeping the morph size realistic might be a help is reducing the excessive redrawing that is claimed to be part of the morphic performance drain. And that is something I'd really like to see improved.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: TOAC: Turn Off Air Conditioner
How can I produce these problems? Clicking to the right of the text is working fine. Resizing my screen and all the various other doomsday scenarios suggested by other commenters does not cause any problems. I will be happy to look at any issues if someone can help demonstrate them to me.
You'll notice that PLM>>itemFromPoint: is used to locate the morph for a click position, and it doesn't care about width. Thats why it works.
The only time I see a difference is if I try to use the halo system to select a StringMorph, in which case I must click on the item, and not somewhere to the right of it. I don't care much about that, but it can probably be taken care of. Oh, and one or two subclasses need their highlighting adjusted. I might get around to that when/if this sacred cow is in my hamburger bun.
Eddie
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "'The general-purpose Squeak developers list'" squeak-dev@lists.squeakfoundation.org Sent: Saturday, August 09, 2003 5:34 PM Subject: RE: [ENH][Refactor] PLMCleanUpStart
While we're looking at this area, here's a suggestion. Can we get rid of the resizing of every morph to be 9999 wide?
The reason for this is mostly to avoid (potentially expensive) resizing of StringMorphs when you resize a PLM. In other words, with your changes (which I haven't tried) it is likely that you have to click exactly on the string and not "to the right" before the string ends. While I don't consider the current solution to be very nice, the UI problems that your solution introduces seem much worse to me.
Cheers, - Andreas
recommend closure of this enhancement. it appears that there have been subsequent changes that break this enhancement badly.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Daniel Vainsencher -
Eddie Cottongim -
Joshua 'Schwa' Gargus -
jp1660＠att.net -
Ned Konz -
Tim Rowledge