At the bottom of this message is a MessageTally on dragging a shape around with 8 connectors attached to it. These connectors have no arrow heads, but spend a fair amount of time dealing with arrow heads.
Ned:
1) Is there some way to optimize this case? 2) Are you drawing an empty arrow on these cases, and spending time building and possibly rotating an empty form, or a form with a short line?
General:
1) I had to comment out the delay at the end of each interaction cycle. While this does mean the CPU is running at 100%, Unix can handle that, and even with high performance set it was taking 14%-30% in waiting on that delay. With it disabled interaction is better, but still not really keeping up with the mouse. 2) It appears that Balloon draws to a form and then BitBlt the form to the screen. Is this correct? It is spending a fair amount of time doing this copying of bits.
It looks like my next task it to think about line drawing and making that faster. Optimizing arrow heads would also help. Any suggestions on how to proceed would be appreciated. A similar app written in Objective-C is about 2x faster / more responsive. The anti-alias of lines as lines rather than curves should be faster, than the current treatment. For those shapes that are not being moved, it should be possible to cache the form that Balloon is creating. Would this work? That could reduce the drawing time for larger diagrams. My test diagram has 3 connectors not affected by the drag.
Michael
- 37857 tallies, 43867 msec.
**Tree** 100.0% {43867ms} PasteUpMorph>>doOneCycle 99.9% {43823ms} WorldState>>doOneCycleFor: 99.9% {43823ms} WorldState>>doOneCycleNowFor: 52.8% {23162ms} WorldState>>displayWorldSafely: |52.8% {23162ms} PasteUpMorph>>displayWorld | 52.7% {23118ms} PasteUpMorph>>privateOuterDisplayWorld | 52.7% {23118ms} WorldState>>displayWorld:submorphs: | 47.3% {20749ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | |46.5% {20398ms} FormCanvas(Canvas)>>fullDrawMorph: | | 46.5% {20398ms} FormCanvas(Canvas)>>fullDraw: | | 30.2% {13248ms} NCAAConnectorMorph>>fullDrawOn: | | |29.7% {13028ms} NCAAConnectorMorph(Morph)>>drawSubmorphsOn: | | | 29.5% {12941ms} FormCanvas(Canvas)>>fullDrawMorph: | | | 29.4% {12897ms} FormCanvas(Canvas)>>fullDraw: | | | 29.4% {12897ms} NCLineMorph(Morph)>>fullDrawOn: | | | 14.3% {6273ms} FormCanvas(Canvas)>>drawMorph: | | | |14.3% {6273ms} FormCanvas(Canvas)>>draw: | | | | 14.1% {6185ms} NCLineMorph>>drawOn: | | | | 12.1% {5308ms} BalloonCanvas>>flush | | | | 12.1% {5308ms} BalloonEngine>>flush | | | | 12.0% {5264ms} BalloonEngine>>copyBits | | | | 12.0% {5264ms} BalloonEngine>>copyLoopFaster | | | | 12.0% {5264ms} primitives | | | 12.6% {5527ms} NCLineMorph>>fullBounds | | | 12.0% {5264ms} NCLineMorph>>computeBounds | | | 6.3% {2764ms} NCLineMorph>>updateArrowContours | | | |5.0% {2193ms} NCLineArrowGlyph>>openForLineWidth: | | | 2.7% {1184ms} NCLineMorph>>arrowForms | | 16.4% {7194ms} SystemWindow(Morph)>>fullDrawOn: | | 13.8% {6054ms} SystemWindow(Morph)>>drawSubmorphsOn: | | |13.7% {6010ms} FormCanvas(Canvas)>>fullDrawMorph: | | | 13.7% {6010ms} FormCanvas(Canvas)>>fullDraw: | | | 13.7% {6010ms} PasteUpMorph(Morph)>>fullDrawOn: | | | 12.6% {5527ms} PasteUpMorph>>drawSubmorphsOn: | | | 12.5% {5483ms} FormCanvas(Canvas)>>fullDrawMorph: | | | 12.4% {5440ms} FormCanvas(Canvas)>>fullDraw: | | | 8.1% {3553ms} NCAAConnectorMorph>>fullDrawOn: | | | |7.8% {3422ms} NCAAConnectorMorph(Morph)>>drawSubmorphsOn: | | | | 7.7% {3378ms} FormCanvas(Canvas)>>fullDrawMorph: | | | | 7.7% {3378ms} FormCanvas(Canvas)>>fullDraw: | | | | 7.7% {3378ms} NCLineMorph(Morph)>>fullDrawOn: | | | | 6.7% {2939ms} FormCanvas(Canvas)>>drawMorph: | | | | 6.7% {2939ms} FormCanvas(Canvas)>>draw: | | | | 6.6% {2895ms} NCLineMorph>>drawOn: | | | | 5.6% {2457ms} BalloonCanvas>>flush | | | | 5.6% {2457ms} BalloonEngine>>flush | | | | 5.5% {2413ms} BalloonEngine>>copyBits | | | | 5.4% {2369ms} BalloonEngine>>copyLoopFaster | | | | 5.4% {2369ms} primitives | | | 4.4% {1930ms} NCUMLDiagramMorph(Morph)>>fullDrawOn: | | | 2.5% {1097ms} NCUMLDiagramMorph(Morph)>>drawSubmorphsOn: | | | 2.3% {1009ms} FormCanvas(Canvas)>>fullDrawMorph: | | | 2.3% {1009ms} FormCanvas(Canvas)>>fullDraw: | | | 2.2% {965ms} NCGrabbableDisplayTextMorph(Morph)>>fullDrawOn: | | 2.2% {965ms} FormCanvas(Canvas)>>drawMorph: | | 2.2% {965ms} FormCanvas(Canvas)>>draw: | | 2.2% {965ms} SystemWindow(Morph)>>drawOn: | 3.2% {1404ms} WorldState>>forceDamageToScreen: | 3.2% {1404ms} DisplayScreen>>forceDamageToScreen: | 3.1% {1360ms} OrderedCollection>>do: 31.9% {13994ms} PasteUpMorph>>runStepMethods |31.9% {13994ms} WorldState>>runStepMethodsIn: | 31.8% {13950ms} WorldState>>runLocalStepMethodsIn: | 30.7% {13467ms} StepMessage(MorphicAlarm)>>value: | 30.6% {13423ms} NCAAConnectorMorph(Morph)>>stepAt: | 28.8% {12634ms} NCLineEndConstraintMorph>>step | 24.3% {10660ms} NCLineEndConstraintMorph>>applyConstraint: | |20.2% {8861ms} NCLineMorph>>verticesAt:put: | | |20.2% {8861ms} NCLineMorph>>setVertices: | | | 19.8% {8686ms} NCLineMorph>>computeBounds | | | 8.2% {3597ms} NCLineMorph>>updateArrowContours | | | |6.4% {2807ms} NCLineArrowGlyph>>openForLineWidth: | | | | 2.3% {1009ms} NCLineArrowGlyph(NCCurve)>>updateBounds | | | 4.8% {2106ms} NCLineMorph>>arrowForms | | | 2.4% {1053ms} BalloonCanvas>>drawGeneralBezierShape...rderWidth:borderColor: | |3.9% {1711ms} NCLineEndConstraintMorph(Morph)>>center: | | 3.8% {1667ms} NCLineEndConstraintMorph(Morph)>>position: | | 2.1% {921ms} NCAAConnectorMorph>>layoutChanged | 3.5% {1535ms} NCLineEndConstraintMorph>>target | 3.1% {1360ms} NCLineEndConstraintMorph(NCConstraintMorph)>>targetPoint | 2.6% {1141ms} MessageSend>>valueWithEnoughArguments: | 2.5% {1097ms} NCLineEndConstraintMorph>>nearestPointToCenterOf: | 2.4% {1053ms} NCUMLDiagramMorph(BorderedMorph)>>intersectionWithLineSegmentFromCenterT o: | 2.4% {1053ms} NCUMLDiagramMorph(Morph)>>intersectionWithLineSegmentFromCenterTo: | 2.2% {965ms} NCUMLDiagramMorph(Morph)>>firstIntersectionWithLineFrom:to: 14.7% {6448ms} HandMorph>>processEvents 8.8% {3860ms} MouseOverHandler>>processMouseOver: |7.4% {3246ms} HandMorph>>handleEvent: | 6.8% {2983ms} HandMorph>>sendMouseEvent: | 6.8% {2983ms} HandMorph>>sendEvent:focus:clear: | 6.5% {2851ms} PasteUpMorph(Morph)>>processEvent: | 6.4% {2807ms} PasteUpMorph>>processEvent:using: | 6.4% {2807ms} PasteUpMorph(Morph)>>processEvent:using: | 6.3% {2764ms} MorphicEventDispatcher>>dispatchEvent:with: | 6.2% {2720ms} MorphicEventDispatcher>>dispatchDefault:with: | 3.9% {1711ms} SystemWindow(Morph)>>processEvent:using: | 3.0% {1316ms} MorphicEventDispatcher>>dispatchEvent:with: | 2.9% {1272ms} MorphicEventDispatcher>>dispatchDefault:with: | 2.2% {965ms} PasteUpMorph>>processEvent:using: | 2.2% {965ms} PasteUpMorph(Morph)>>processEvent:using: | 2.2% {965ms} MorphicEventDispatcher>>dispatchEvent:with: | 2.2% {965ms} MorphicEventDispatcher>>dispatchDefault:with: 3.8% {1667ms} HandMorph>>handleEvent: 2.2% {965ms} HandMorph>>sendMouseEvent: 2.2% {965ms} HandMorph>>sendEvent:focus:clear: 2.2% {965ms} PasteUpMorph(Morph)>>processEvent: 2.2% {965ms} PasteUpMorph>>processEvent:using: 2.2% {965ms} PasteUpMorph(Morph)>>processEvent:using: 2.2% {965ms} MorphicEventDispatcher>>dispatchEvent:with: 2.2% {965ms} MorphicEventDispatcher>>dispatchDefault:with: **Leaves** 17.7% {7764ms} BalloonEngine>>copyLoopFaster 3.4% {1491ms} OrderedCollection>>do: 3.1% {1360ms} Array(SequenceableCollection)>>do: 2.4% {1053ms} SmallInteger(Magnitude)>>max: 2.1% {921ms} NCAAConnectorMorph(Morph)>>hasExtension
**Memory** old +849,332 bytes young +42,564 bytes used +891,896 bytes free -891,896 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 1235 totalling 3,939ms (9.0% uptime), avg 3.0ms tenures 17 (avg 72 GCs/tenure) root table 0 overflows
On Wednesday 29 December 2004 2:16 pm, Michael Latta wrote:
At the bottom of this message is a MessageTally on dragging a shape around with 8 connectors attached to it. These connectors have no arrow heads, but spend a fair amount of time dealing with arrow heads.
- Is there some way to optimize this case?
Actually, they do have arrowheads, it's just that the arrowheads are very simple (i.e. a closed square end).
It looks as if you have Connectors on PasteUpMorphs inside SystemWindows, is that right? And others are just out in the World.
Are these connectors smooth curves? It looks as if at least some of them might be. Have you tried making them segmented lines and seeing if the performance is better (it should be)? In my tests, it seems to take about twice as long to re-position/re-draw the curves, even if they're not really curved.
So here's an obvious optimization: if there are only two vertices (the ends), draw smooth curves as segmented curves. However, then the ends would also be drawn as a segmented shape. If your ends don't really have any curves in them, that's OK (i.e. if they are all straight lines). Perhaps I need a Preference for this? Or we could just look at the end decorations and see if they have any curves.
When I try the same thing with segmented lines with no bends, I see about 35% of the time being spent in NCLineMorph>>computeBounds, and about 28% in Delay>>wait, 7% in the event loop, and the remaining 30% split between flushing bits to the screen (13% or so), extra logic in step (6%) and some other methods.
- Are you drawing an empty arrow on these cases, and spending time
building and possibly rotating an empty form, or a form with a short line?
I'm drawing a closed polygon or bezier curve (depending on whether the line is curved). The end decorations just contribute their line segments or curve segments to the closed region.
The computeArrowForms is actually just for (a) more accurate bounds testing, though I certainly could use a rectangle containing all the vertices and control points of the arrow shape for that, and (b) hit testing, but we could be lazy about computing the forms until we actually need them for that purpose.
It would be useful to make sure that the ratio of calls to computeArrowForms to movement is 1:1 (or whatever is the correct ratio).
I did this:
* make a Workspace; choose "create textual references to dropped morphs". Drop the shape to which the 8 connectors are attached into the workspace to get its name. In my case it was 'tr3756'.
* run this code in the Workspace:
MessageTally tallySends: [ tr3756 position: tr3756 position + (3@3). World doOneCycle. ]
When I look at this, I see that computeBounds (the big offender) is being called 64 times (or is it 80?), but there's only 8 connectors. Is this right? I don't know, but it sounds suspicious and could be somewhere to start looking. Clearly, if we could cut that down to 8 times it would be a big improvement.
| | | | | | | | | | 94 NCLineMorph(Morph)>>fullDrawOn: | | | | | | | | | | 20 NCLineMorph>>fullBounds | | | | | | | | | | |32 NCLineMorph>>computeBounds | | | | | | | | | | | |8 NCLineMorph>>updateArrowContours
later...
| | | | | 16 NCLineEndConstraintMorph>>step | | | | | |11 NCLineEndConstraintMorph>>applyConstraint: | | | | | | |8 NCLineMorph>>verticesAt:put: | | | | | | | |24 NCLineMorph>>setVertices: | | | | | | | | |32 NCLineMorph>>computeBounds | | | | | | | | | |8 NCLineMorph>>updateArrowContours | | | | | | | | | | |48 NCLineArrowGlyph>>openForLineWidth: | | | | | | | | | | | |16 NCLineArrowGlyph(NCCurve)>>updateBounds | | | | | | | | | | | | |96 NCLineArrowGlyph(NCCurve)>>boundingBox
There's also 64 calls to layoutChanged (each of which calls submorphBounds), 80 calls to NCLineMorph>>arrowForms (all from computeBounds), in 2 groups of 40, each of which group draws the arrows the 16 times that you'd expect), etc.
| | | | | | | | | | 94 NCLineMorph(Morph)>>fullDrawOn: | | | | | | | | | | 20 NCLineMorph>>fullBounds | | | | | | | | | | |32 NCLineMorph>>computeBounds | | | | | | | | | | | |8 NCLineMorph>>updateArrowContours | | | | | | | | | | | | |48 NCLineArrowGlyph>>openForLineWidth:
Now, I read the above as "though there are 20 calls to fullBounds, we somehow have 32 calls to computeBounds". In which case that might indicate that some unwanted recursion is going on. Or that MessageTally is fooling me.
- I had to comment out the delay at the end of each interaction cycle.
While this does mean the CPU is running at 100%, Unix can handle that, and even with high performance set it was taking 14%-30% in waiting on that delay. With it disabled interaction is better, but still not really keeping up with the mouse.
What I do for debugging GUI performance is usually something like this:
MessageTally spyOn: [ 100 timesRepeat: [ tr3756 position: tr3756 position + (3@3). World doOneCycle. ] ] toFileNamed: 'messageTally.txt'.
- It appears that Balloon draws to a form and then BitBlt the form to
the screen. Is this correct?
Kinda. It does some internal caching. Also, at the end of every drawing to the Display of morphs that use asBalloonCanvas there is a flush.
It is spending a fair amount of time doing this copying of bits.
I didn't see that in my trace, though I do in yours. Are these really long connectors, or ones with bends in them? It could be that there is a really big area being covered.
It looks like my next task it to think about line drawing and making that faster. Optimizing arrow heads would also help. Any suggestions on how to proceed would be appreciated.
Well, the usual method... attack the slowest stuff first and repeat.
A similar app written in Objective-C is about 2x faster / more responsive. The anti-alias of lines as lines rather than curves should be faster, than the current treatment.
For those shapes that are not being moved, it should be possible to cache the form that Balloon is creating. Would this work?
Yes; you could simply make a caching connector by adding a form. But the form would have to be as big as the bounding rectangle of the connector, which could be at least as big as the screen; that's a lot of memory. Or you could keep a collection of smaller rectangles that would cover the line instead.
If your drawings have a lot of connectors under other connectors, perhaps making such a connector that caches its form in a collection of small rectangles might be the best first approach.
Or maybe (since these are bezier curves) you could just have N+1 (possibly overlapping) rectangles per N segments. This would cut down the number of bits that would need to be moved, if the DamageRecorder doesn't merge the rects on you (see below).
That could reduce the drawing time for larger diagrams. My test diagram has 3 connectors not affected by the drag.
If they aren't in an area that is invalidated by moving other connectors over them, their drawing speed doesn't matter. If you turn on the Preference 'debugShowDamage' you will see the areas that are being invalidated and later redrawn.
Another thing that might help with both redrawing of static areas of the screen would be to invalidate smaller rectangles along the line. However, you'd have to be careful, as the DamageRecorder will eventually merge the smaller rectangles so as not to redraw too much. There's a balance between drawing the same Morph multiple times (clipping to different rectangles) and drawing more morphs once.
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains what they're designed to do? What problems they're meant to solve? I have them on my system, but I can't figure out how/where to use them.
On Wed, 29 Dec 2004 16:13:27 -0800, "Blake" blake@kingdomrpg.com said:
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains what they're designed to do? What problems they're meant to solve? I have them on my system, but I can't figure out how/where to use them.
As with any Squeak-related question of this sort ("What is xxx?") be sure to check the Swiki to see if there's a page devoted to it. (There usually is.)
Go to http://minnow.cc.gatech.edu/squeak and Search for "Connectors", and you'll find:
http://minnow.cc.gatech.edu/squeak/1773
Actually, it would be really nice if the Swiki let you do a search for page titles only, that would be a lot faster for this case. I often want to do this. Consider this a ComSwiki request! (Although I don't know if ComSwiki is still being worked on, and maybe SmallWiki already does this.)
- Doug
You can do this in ComSwiki sort of. Just insert what you are looking for in the page in CamelCase after the swiki URL. So,
http://minnow.cc.gatech.edu/squeak/Connectors
works.
ComSwiki is still being worked on.
Peace and Luck!
Je77
On Wed, Dec 29, 2004 at 04:28:14PM -0800, Doug Way wrote:
On Wed, 29 Dec 2004 16:13:27 -0800, "Blake" blake@kingdomrpg.com said:
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains what they're designed to do? What problems they're meant to solve? I have them on my system, but I can't figure out how/where to use them.
As with any Squeak-related question of this sort ("What is xxx?") be sure to check the Swiki to see if there's a page devoted to it. (There usually is.)
Go to http://minnow.cc.gatech.edu/squeak and Search for "Connectors", and you'll find:
http://minnow.cc.gatech.edu/squeak/1773
Actually, it would be really nice if the Swiki let you do a search for page titles only, that would be a lot faster for this case. I often want to do this. Consider this a ComSwiki request! (Although I don't know if ComSwiki is still being worked on, and maybe SmallWiki already does this.)
- Doug
On Dec 29, 2004, at 6:28 PM, Doug Way wrote:
Actually, it would be really nice if the Swiki let you do a search for page titles only, that would be a lot faster for this case. I often want to do this. Consider this a ComSwiki request! (Although I don't know if ComSwiki is still being worked on, and maybe SmallWiki already does this.)
- Doug
Searching on minnow is painfully slow. Try using google with site:minnow.cc.gatech.com, i.e. "connectors site:minnow.cc.gatech.edu". Responds in 0.22 seconds with Conectors at the top of the list.
On Wednesday 29 December 2004 4:13 pm, Blake wrote:
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains what they're designed to do? What problems they're meant to solve? I have them on my system, but I can't figure out how/where to use them.
There is a description here: http://minnow.cc.gatech.edu/squeak/1773
But I can also say this: it started out as a single kind of Morph -- a ConnectorMorph -- and as I found that I needed or wanted other kinds of morphs to use in my drawings, I added them to the package.
On Wed, 29 Dec 2004 16:32:59 -0800, Ned Konz ned@squeakland.org wrote:
But I can also say this: it started out as a single kind of Morph -- a ConnectorMorph -- and as I found that I needed or wanted other kinds of morphs to use in my drawings, I added them to the package.
OK, I've read the Swiki and I know what they are. But what're they for?<s> I mean, a lot of people (relatively speaking) seem to have really gravitated to them--what're they used for?
Blake wrote:
On Wed, 29 Dec 2004 16:32:59 -0800, Ned Konz ned@squeakland.org wrote:
But I can also say this: it started out as a single kind of Morph -- a ConnectorMorph -- and as I found that I needed or wanted other kinds of morphs to use in my drawings, I added them to the package.
OK, I've read the Swiki and I know what they are. But what're they for?<s> I mean, a lot of people (relatively speaking) seem to have really gravitated to them--what're they used for?
Well, I use them for Jacarandá (http://minnow.cc.gatech.edu/squeak/Jacaranda) and they are also used by Trygve on his SRE project that released a couple of weeks ago, and on many other projects that I don't remember their names now.
Regards, Hernán
Blake wrote:
But I can also say this: it started out as a single kind of Morph -- a ConnectorMorph -- and as I found that I needed or wanted other kinds of morphs to use in my drawings, I added them to the package.
OK, I've read the Swiki and I know what they are. But what're they for?<s> I mean, a lot of people (relatively speaking) seem to have really gravitated to them--what're they used for?
I use them to set up time-wise or logical relationships between musical elements represented by boxes.
example on this page: http://www.zogotounga.net/comp/squeak/sqgeoex.htm
Stef
On Wednesday 29 December 2004 4:51 pm, Blake wrote:
OK, I've read the Swiki and I know what they are. But what're they for?<s> I mean, a lot of people (relatively speaking) seem to have really gravitated to them--what're they used for?
Another interesting example is Jim Rosenberg, who uses them for hypertext poems:
http://www.well.com/user/jer/index.html
http://www.well.com/user/jer/current.html
On Wed, Dec 29, 2004 at 04:13:27PM -0800, Blake wrote:
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains what they're designed to do? What problems they're meant to solve? I have them on my system, but I can't figure out how/where to use them.
I use Connectors whenever I want to make a diagram or picture, especially when I want to show something to a person accustomed to PowerPoint slides.
Think of it as a diagramming tool where the objects in the diagram just happen to be live objects in Squeak. Sort of like a Powerpoint slide that comes to life when you click on something in the diagram.
Many thanks to Ned for creating Connectors. And while I am at it, I should mention the excellent Plot Morph package by Diego Gomez Deck, which I have also been using recently (well, today actually) for data presentation. Both Connectors and Plot Morph are wonderfully useful for presentations and data analysis.
Dave
On Wed, 29 Dec 2004 18:43:15 -0800, DClarke@fadal.com wrote:
what're they used for?
What do other folks buy and use MS Visio for? Same thing.
On Wed, 29 Dec 2004 22:15:15 -0500, David T. Lewis lewis@mail.msen.com wrote:
I use Connectors whenever I want to make a diagram or picture, especially when I want to show something to a person accustomed to PowerPoint slides.
Think of it as a diagramming tool where the objects in the diagram just happen to be live objects in Squeak. Sort of like a Powerpoint slide that comes to life when you click on something in the diagram.
OK, cool.
On 29-Dec-04, at 7:15 PM, David T. Lewis wrote:
On Wed, Dec 29, 2004 at 04:13:27PM -0800, Blake wrote:
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains what they're designed to do? What problems they're meant to solve? I have them on my system, but I can't figure out how/where to use them.
I use Connectors whenever I want to make a diagram or picture, especially when I want to show something to a person accustomed to PowerPoint slides.
So when you make a presentation using connectors and plotMorphs, how do manage the "slides" ? Surely the screen isn't big enough for your presentation.
Do you use book Morphs? ..or something else?
THEj
Think of it as a diagramming tool where the objects in the diagram just happen to be live objects in Squeak. Sort of like a Powerpoint slide that comes to life when you click on something in the diagram.
Many thanks to Ned for creating Connectors. And while I am at it, I should mention the excellent Plot Morph package by Diego Gomez Deck, which I have also been using recently (well, today actually) for data presentation. Both Connectors and Plot Morph are wonderfully useful for presentations and data analysis.
Dave
Quoting j thej@shaw.ca:
I use Connectors whenever I want to make a diagram or picture, especially when I want to show something to a person accustomed to PowerPoint slides.
So when you make a presentation using connectors and plotMorphs, how do manage the "slides" ? Surely the screen isn't big enough for your presentation.
Do you use book Morphs? ..or something else?
THEj
I just use one Morphic project as one slide. I do this in full screen mode, which especially looks interesting as people are not used to the idea having a screen where you do not see any GUI elements and still can work in with ease. Well there are the flaps. I created my own flaps (parts bin) where I keep StringMorphs in different point sizes and colors to add to the consistency.
(Side note: well Tim, you see, I do not use a top menu bar .....)
I often have one central slide (like in the 'Worlds of Squeak') from where I can branch off to separate slides and come back to the point of departure - like a brain map with 'sub-brainmaps', where I have graphical links to. It is easier for me and the poeple as well to present something. (A kind of top-down approach).
The ProjectViewMorph links are very nice. If you have e.g. a dark blue background in the central slide it looks very nice. You can resize them to accomodate to your needs.
I often have another project apart called 'Slides' where I create the slides. A slide can be reused in different presentations then more easily.
I added a 'add-jump-to-project' menu entry to the class StringMorph, so any string in Morphic world can be a hyperlink to another project as well.
In addition I changed the snap in grid distance to a relatively large value, so that the elements are easier to align.
And what is really astonishing. If you have done these preparations mentioned above, you can work on the presentation during presenting, i.e. collect feedback and put it down for everybody to see (like on a whiteboard).
In fact Squeak can be used nowadays as a 'dynabook' if you are ready to take on some effort to customize it for your needs.
On an off I have been working on a HTML export function (using DIVs for RectangleMorphs and CSS for absolute positioning). It works quite nicely and in the not so distant future I will put it on SqueakMap. In the web browser I switch as well to full screen mode (often F11-key).
HTH
Hannes
Le 2004/12/29, Blake blake@kingdomrpg.com écrivait :
I've been fascinated by--and trying to follow--the discussions on connectors over the past month and have just one question:
What are they?
I mean, can anyone give me a "high concept" definition that explains
what
they're designed to do? What problems they're meant to solve? I have
them
on my system, but I can't figure out how/where to use them.
Lot of things for sure this is a kit to make graphs, conceptuals ones, data modeling, etc...
few examples see the link below. Everything is made with Connectors except the two GUI.
Hope this help
squeak-dev@lists.squeakfoundation.org
-
Blake -
David T. Lewis -
Doug Way -
Hernan Tylim -
hjh-sqlist＠lexdb.net -
j -
Jochen F. Rick -
Michael Latta -
Ned Konz -
Raymond Asselin -
Stéphane Rollandin -
Wileks Joiner