Introduction to Cocoa Graphics, Part 2
Pages: 1, 2, 3
Changing the characteristics of paths
It's possible to change the characteristics of Bezier paths via several methods. For example, we can change the thickness of a stroked path using the method –setLineWidth:, where the argument is a float indicating the width of the line in points. We can change the thickness of the lines of our triangle by adding the following just before we send a stroke message to triangle:
[triangle setLineWidth:10];
This will make our drawing look like the following:
|
If you set the line width to 0 using this method, then the path will be stroked with the smallest width that can be displayed on the screen. I choose a thick line width here to bring out some features about the way path elements are joined to each other.
First, notice how the lower right vertex of the triangle is a very sharp point that extends far beyond what we originally intended for our triangle. The image below shows a thin green line superimposed on top of the thicker red line to highlight the effect I’m speaking of.
|
The reason for this is that by default, lines in a path are joined together using a so-called miter join where the outside edge of the two intersecting lines are extended to a point. This default join style is defined the constant NSMiterLineJoinStyle, which we use to identify the join style in code. We can fix this problem in several ways.
One, we can change the line join style to either NSRoundLineJoinStyle or NSBevelLineJoinStyle using the method -setLineJoinStyle. For example, if we wanted to make the vertices rounded, we would pass the constant NSRoundLineJoinStyle as an argument to setLineJoinStyle:
[triangle setLineJoinStyle:NSRoundLineJoinStyle];
Alternatively, we can flatten the corners by using NSBevelJoinStyle. In the image below, I show the three line join styles side-by-side with a representation of the original path drawn in green.
|
Line joining, however, is not the end of our woes here. Remember our discussion about closing paths and the line join issues associated with it? Well, here is a perfect example of what happens when the path is not officially closed, despite your shape having the appearance of being closed.
Notice in the lower left corner that the lines are never joined. The reason for this is simple enough: this corner is both the start of the path and the end of the path. We never say that these two points -- despite them being the same point -- should be joined. To fix this, we send a closePath message to triangle after our last construction command to close the path off, and now any join style will apply correctly, as shown below:
|
The final code the produced this image is as follows:
- (void)drawRect:(NSRect)rect {
//The three vertices of the triangle
NSPoint p1 = NSMakePoint(100, 100);
NSPoint p2 = NSMakePoint(200, 300);
NSPoint p3 = NSMakePoint(300, 100);
NSPoint c1 = NSMakePoint(200, 200);
NSPoint c2 = NSMakePoint(200, 0);
// Constructing the path
NSBezierPath *triangle = [NSBezierPath bezierPath];
[triangle moveToPoint:p1];
[triangle lineToPoint:p2];
[triangle lineToPoint:p3];
[triangle curveToPoint:p1 controlPoint1:c1 controlPoint2:c2];
[triangle closePath];
// Fill the path
[[NSColor blueColor] set];
[triangle fill];
// Draw the outline
[triangle setLineJoinStyle:NSRoundLineJoinStyle];
[triangle setLineWidth:10];
[[NSColor redColor] set];
[triangle stroke];
// Draw representation of original path
[triangle setLineWidth:0];
[[NSColor greenColor] set];
[triangle stroke];
}
The end
So there you have it! This is how you can create any shape that you may need. NSBezierPath has many more methods that do useful things, many of which we will cover in future columns.
As always, I recommend that you become familiar with the NSBezierPath class reference if you haven’t done so already. For now, I leave you with these most useful tools with which you can do a lot. In the next column we will start to learn about how you can interact with elements of your drawing on screen using the mouse, so stay tuned for some good stuff. See you then!
Michael Beam is a software engineer in the energy industry specializing in seismic application development on Linux with C++ and Qt. He lives in Houston, Texas with his wife and son.
Read more Programming With Cocoa columns.
Return to the Mac DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 30 of 30.
-
Programming With Cocoa series dying?
2001-11-26 19:41:16 retro [Reply | View]
-
Programming With Cocoa series dying?
2001-11-26 20:39:39 Michael Beam |
[Reply | View]
Hey everyone, thanks for checking in on the state of the column, i appreciate it! Let me respond by saying i second everything Derrick said. I don't have any plans on letting this column fade away, and I apologize for my lack of activity in the forum and perceived lack of interest. I am still as interested and enthusiastic about this column as i ever was.
So what gives, you ask? Well, I've got 22 hours of class this semester, and i graduate in 2 weeks. Unfortunately school has a way of overshadowing so much else in life. I'll do my best to watch the boards more closely in the next month or so ("but, Mike, you said you graduate in 2 weeks, a month?" Get this, i have to take finals _after_ i walk across the stage in my robe. Weird.), and after that i'll be more active like i was at the end of the summer.
BTW, for everyone who has sent me email, and i've failed to reply, I apologize to you too. I do appreciate all the email you send me, and read all of them.
So, thats what's happening on my end of the column. Hope you all enjjoy all the stuff Derrick has coming. I know i'm looking forward to it! -
Programming With Cocoa series dying?
2001-11-26 20:03:22 Derrick Story |
[Reply | View]
Ah, the rumors of Mike's Cocoa column death are indeed premature. Mike has continued to meet his deadlines and provide us with solid tutorials.
I, on the other hand, the evil managing editor, have noticed a decline in traffic for our beloved Cocoa column. So, instead of running the articles every two weeks as before, I've slowed down the pace a bit.
But, I've also looked for ways to augment Mike's column with Cocoa-related content. And later this week you'll get a peek at what I mean.
On Friday, Nov. 30, not only are we going to run the next installment of Mike's column, but we're running a second article introducing F-Script, a terrific tool that makes Cocoa programming easier. I have three articles in that series that will run on the same days as Mike's columns.
I'm hoping that this approach will rekindle some of the original interest we had in the Cocoa series. Because between you and me, this is one of the most important developer topics related to Mac OS X.
Thanks for your comments, and we're here following what you have to say.
--Derrickk -
hmmmm F-script
2001-11-27 08:55:34 psheldon [Reply | View]
I vaguely remember something about Applescript getting amplified in December or its own builder and my promised developer cd for September, so I am waiting for these two things, the column and your cd.
I hope that we will continue to have Mike's graphics story continue when he can. I thought he was just off for Thanksgiving and sort of tried to cover responses so we wouldn't all get lonely.
I hope the scripting promotes interapplication communication. I had hoped to get a foundation for supercomputer clusters by going through the objective c thinking. Maple kind of wanted me to do everything in Maple to advertise their "box". I need more to learn how to think "out of the box" and maybe even help build the "box". I got a c program to talk to a Maple program a few months back. The glory has faded from my memory.
I'll look forward to this F-script detour whatever it is (I can stand being curious) and to Mike getting back to the graphics tricks when his school life lets him. -
hmmmm F-script
2001-11-27 09:38:29 Derrick Story |
[Reply | View]
Well Mike is back this Friday with a terrific column (IMHO), and it will be augmented with a second article on F-Script.
Bottom line: We're going to continue to publish "Programming with Cocoa" regularly, and we're going to add more Cocoa content to run with it.
Our dedication to covering Cocoa is as strong as ever. -
Cocoa in general
2001-11-29 06:56:18 retro [Reply | View]
That's good to hear! I'm really glad that the Cocoa articles are continuing, you are doing a great job Mike, as are all at O'Reilly Net. I can't begin to tell you how useful your tutorials have been to me and my Programmer's SIG, I use them all the time. Think about it Mike, you are helping to bring a whole new generation of Mac Programmers into the fold.
Believe me, I know what finals are like. And yes, those dratted Saturday finals are a killer, especially after you have already "graduated".
The toughest thing about learning Cocoa is to understand the framework, and know what parts should do what and where. There are altogether too few resources available for this purpose, although it looks like a couple more books will be arriving soon.
Anyone have a word if there is going to be a "Cocoa in a Nutshell" from O'Reilly?
-
tried with 10.1 PB/IB?
2001-11-22 11:56:22 dwchris [Reply | View]
(Sorry for posting this here, but my post under the older article (Legs for Simple text Editor) went unanswered and I figure that no one is reading the older ones.)
has anyone built SimpleTExtEdior with Legs project with the 10.1 dev tools? I find that they are subtly different and you cant follow the instruction steps in the article anymore.
I trudged on anyway, but had to instantiate the mydocument class to get anything to work.
When I did, it builds okay, but I get the error "cant save document" mentioned in the other messages. but none of the pitfalls there seem to apply. the outlet appears to wired up etc. When I debug, after a user save, my dataRepresentationOfType routine is called but evidently something goes wrong. -
tried with 10.1 PB/IB?
2001-11-22 13:12:19 psheldon [Reply | View]
Something in an old project Mike Beam had written column on didn't work and I was sure happy he changed the subject. I don't remember what it was that didn't work any more, but it was written just be 10.1 emerged.
Once I canibalized a speech synthesis example from Apple to make it simpler to see how better to canibalize from it. I did this in the beta version of os x. On public release, it wouldn't recompile. The target program might have continued working with all its linked up stuff, but the frameworks had adjusted their positions subtly. I wound up changing imports or includes in headers on some guess and got my "toodles" speech synthesis for dummies program going again.
I got way lost trying to put together with toodles, the text editor you had with the saving stuff that's so fundamental in any programming learning . So, I realized I had only valued with some pain learning how to build from pieces but not actually yet learned how to build from pieces .
Though it hasn't quite taken root in me yet, more important that the text editor is to get some feel of the memory management stuff. I think this release and retain is a bizarre spin on scope and "name space" peculiar to objective c. Understand this stuff and you'll know powerful things that you best not speak of in a c++ crowd. Apple is supposed to do something with combining objective c and c++ less apologetically than the first example they showed. Scope conceptualization might be important to revisit in December.
When, in Beta os x, I first started reading the external references such as ObjC.pdf, I worried. I can force myself to sit down and read something, but, if no connections happen in my brain to raw painful experience, it probably is going to go down the bit bucket. So, I gave myself pain by canibalizing things, spending days with tutorials making simpler dumber things where I could see what was going on. I could sort of read the insides of Simon and know what was going on, but could I look up stuff to build Simon ex nihilo, maybe nobody can.
I did some stuff where I wet my feet in using the classes tab and hopping to helpviewer to search the class methods to get a feel what was going to go on in the next lesson, but not too long . I anticipated a bit of struggle to put from sketch something doable . Sketch looks like an enormous search space .
It seemed plausible that Mike was going to remind us of some of the things we learned, such as enumerations or mutable NSArrays of NSBezierpaths that you could build at run time and port into drawRect. Then I was satisfied that I had gone through just enough sweat to make me value stuff when he "did it for me" and sort of spoon fed.
I hope MIke and Oreilly notices the important thing that we noticed, that some of the old projects might not work and might need to be rewritten if a textbook ever comes out of this column or these threads.
I have noticed a pattern in a very wise man of modules sort of self contained stuff. The end of these modules heavily depends on the beginnings and the wise man thought and presented faster as he got on in the module, to rapidly rehearse or review the learned language, but learning something knew he started afresh and slow He, in fact, started himself personally much much slower, as he spent many hours preparing his class notes for presentation.
Mike, Oreilly and Apple probably don't want to lose new students either.
Here's a possibility. PB has a toolbar you might have gotten used to. There is also, however, a menu item that says run targets. Download his obsolete source and the targets won't also be obsolete, they'll work. Download his completed obsolete source code but don't clean the targets which recompiling will do maybe! Run the targets from the menu. I believe Apple defaulted to clean target and compile link and run as the default icon. As far as I could figure, you got to "clean the targets" to have the classes tab work. So move the target from the folder they had been in to see what the obsolete code does and, if you get braver than me, clean compile link and run to index appropriately to see how the frameworks and classes have shifted (if that's even what it is). The thing is seeing the way the code was supposed to work and reading through the code might get rid of any worries you weren't up to speed with the rest of us. A lot of us don't know how to debug obsolete code either.
Almost remember in your darkest hour that though some may say they have made debugging a predictable science, they only say that because they aren't having a darkest hour themselves at the time.
;-)
That's as close as I want to get to debugging what went wrong with the texteditor columns, going back and finding it doesn't work would scare me more than just hearing it didn't work from you.
;-)
I got burned with that speech editor saver marriage I was trying to do.
I still fantasize, every once in awhile to make an os x version of hearit, an Apple os 9 and older control panel that lets your computer read anything your mouse selects in any program. The speech synthesis example would highlight the words it was reading making it excellent for teaching reading phrases to kids in the summer reading program and to be able to do that in interapplication communication or something to any application from an os x hearit would be supercool to beat Apple to doing, sort of a Holy Grail to aspire to.
I don't think my writing is too sharp today, I hope I've lifted you.
-
curveToPoint
2001-11-19 13:34:12 dwchris [Reply | View]
Why do I get the error "(NSBezierPath *) doesnt respond to curveToPoint"? Do I have to declare as some other object to get this method?
-
Question about method in NSBezierPath
2001-11-18 08:39:00 retro [Reply | View]
I've been playing around with the NSBezierPath class and have come across a method that doesn't seem to work. The method is - (void) appendBezierPathWithArcFromPoint:toPoint:radius:
Calling this method does not seem to produce a line on my machine. I know that I'm not exactly writing to Apple about a possible bug, but I thought that maybe someone else out there could try this out and see if they get any real results. -
got a great doubt
2001-11-19 20:33:02 psheldon [Reply | View]
I have gotten a good nights sleep, but all day rehearsed the feelings for a good observing story of being out alone in fog coming up with theories on where fog wasn't. 17 rehearsals that I had to put to bed after getting too excited about writing it up for three er two hours.
The idea of Bezier curves is to match not only endpoints but their tangents. This requires a cubic curve with its degrees of freedom afforded by coefficients of a cubic polynomial.
If someone building a framework or class of methods told Apple management that it was possible to take a circle fix its radius and two points it passes through and also make sure that there was a common tangent, it could very well be that Apple management didn't want to hear that was overdefining a problem or worse that there is no royal road to mathematics.
I myself went on a dark country road through a lot of fog, but that's another story.
Now, by sending this judgement call on Apple management, I am flaming myself, because I know the way my brain works. As soon as I write down something and try it out on someone, I worry that I am dead wrong. This is the kind of intellectual stimulation that can lose you a job but gain you enlightenment.
I am writing this flaming judgement call to intellectually stimulate myself into such embarrassment that I will figure out how Apple management was right to expect this.
How can I proceed out in such blind faith in such fog?
I believe one of my professors theorized at seeing neutrinos periodic detection matching an orbital frequency of cygnus x 1. I remarked, stupidly, to the experimentalist that he couldn't possibly have observed this because the neutrino intensity or shot rate was lower than the nyquist sampling frequency, I insulted the beloved experimentalists integrity of observation. Realizing my feu pa (I spell French and English terribly), I hurriedly set to making a fourier transform simulation to prove that the beloved experimentalist hadn't lied. I saw the period creap up out of the undersampled shot noise. I went to Ivor Page who said I had been attempting the impossible to beat the Nyquist sampling theorem and expressed my results. This immediately cleaned up his memory of what was and wasn't impossible and he showed me a paper about Poisson shot noise antaliasing from Lucasfilm.
Though shot noise, on the average may be undersampling, if you look long enough you will see high frequencies emerge.
It was the extreme embarrassment at destroying the credibility of my friend that inspired my researches and paradoxically my friendly beloved experimentalist wrote an abbreviated confident summary of my glorious victory in the terse words "We had a sufficient number of events to insure we saw this periodic motion". With that air of confidence, he was never challenged again on this point, nor did the beloved experimentalist have to cite me.
Apple may well dismiss me with an equally pithy statement such as "We knew we were right all along" but such people don't have an adventure of chasing meteors through fog with their dog utterly alone while a world sleeps, so cool. I will embarrass myself and so let the olympic flame be lit!
;-)
Boy am I gonna get inspired real fast or else. -
what is this thing called triangle?
2001-11-19 20:47:37 psheldon [Reply | View]
Embarrassment made me doubt doubt.
;-)
Bezier class includes methods such as lineto and moveto that will not match tangents and this sets a precident for this other sort of thing getting into the class. I'm also recalling that it makes sense it be in the class without bugs because I recall that there was an option for rounding the corners of a border, so that Apple coders would have gotten the bugs out from that concept, though it is not precisely the same problem, plausibly a similar one. So now I must try to code not so much fearing that I will spend a long time while it doesn't work fearing that Apple might be wrong. The game's afoot! -
changed one line of code for info
2001-11-19 21:36:51 psheldon [Reply | View]
We saw triangle was of class you investigated, NSBezierpath class and not Bezier class. Sorry, my memory became lazy. Must have precise memories as computers are unforgiving.
;-)
Info (in subject line), as defined by AI guys is surprise (for me sometimes extreme confusion).
Commented out line with method curveToPoint to put in your investigated method, appendBezierPathWithArcFromPoint. I checked on radius, not an integer but rather a float, which with hindsight makes sense on a raster because a hypotenuse is irrational and I might like to turn that triangle with Bezier bent bottom into an Apple pie (forgive the pun).
I didn't figure the hypothenuse of 200 and 100 right triangle, but grew impatient and made a radius 200.0 to type match, taking no chances to find this alleged bug.
I got a triangle not a pie. Oh, maybe your method didn't do anything and closePath did.
I commented out closePath.
I lost the red and green strokes on bottom but got a triangle fill. Plausibly fills should spill all over if they are to open objects, that's the way quickdraw opcodes work.
Now, I doubt Apple again. Which way is this float pointing? Was the pie to curve in or out? Tried with and without closePath and got a straight triangle fill.
Note:
My search space is doubling because I don't have one bit facts:
1.What is this closePath doing when the triangle fill is straight, do we have a triangle or don't we.
2. What difference, if any, does sign of radius float make. How do I specify which way the arc curves to make an Apple pie or Apple dent.
When my puzzlement increases like this, I need to give things a rest to get a heuristic in the search, otherwise I keep doubling up things to try and fill up my "chess board" with more than the grains of wheat or sand in the world, however that story goes.
A heuristic comes to me in a morning vision when thinking out of the box.
Gotta get a good nights sleep and then back at it!
Sorry, that's the way my brain works and I am quite happily unemployed. So far it looks like appendBezierPathWithArcFromPoint is also not working.
;-) -
no morning vision heuristic, ;-(
2001-11-20 09:29:58 psheldon [Reply | View]
Remain clueless how to guess what's going on right or wrong in this method. Miss Carolyn Rose's prose before procedure descriptions in Inside Mac, but a person can only write so much in a lifetime.
;-(
She, however, did define this ordered style in what I hope our thread might evolve into the documentation and improvements. -
thinking in box, curve out of box ;-)
2001-11-19 22:42:06 psheldon [Reply | View]
Lay awake and thought, what if first argument attached to first part of your method name, ...ArcFromPoint, meant to draw the arc with a compass point at that point . It didn't make sense to say append... as well as remind the point you were at to append to, so an alternate hypothesis on that argument dawned on me and seemed to have biasing evidence toward it .
Well, setting the radius at 200.0 drew the curve with that radius and tangent to the other parts of the Bezier path outside the cliprect or whatever it is now called, but for thrills I tried other than Apple pie hypothesis radii that were too short. Now, this method is drawing an Apple dent, but, not with the compass point at the apex where I thought I had put it, but out there off cliprect in the opposite direction so as to insure tangency. I tried various floats smaller than 200.0. Negative radius drew nothing nor did fill with the apex from point.
Summary, I got it to draw but did not confirm my alternate interpretation of the argument due to redundancy dissonance, that interpretation being I was placing a compass point. I'm still lost and maybe now ready to sleep for that heuristic rather than constantly rise with blind haymaker hypotheses. -
first sample code and story
2001-11-21 09:54:45 psheldon [Reply | View]
Two hours and forty five minutes of commenting got me hot to it.
I was, at first, frustrated that I couldn't color code the paths differently to remember who did what and then I started in my mind to grasp what was going on without color coding by commenting out certain strokes.
The fog cleared. I always start with intense fog and then I get smart.
I rewrote the code so I could have one place to change p1's x coordinate etc. and see what happened and confirmed your hypothesis really good in all cases except the one you gave which was only confirmed by your "robust fuzzy thinking".
I must train in a pool doing laps now, but brief you on the results here :
I got arcs to draw precisely from p1 to be tangent to that imaginary line as I lengthened what I called the base (line p1-p2) by moving p2 away farther. With the staging in variables I only had to change the value of float x2=...; and I saw many cases exactly confirming your hypothesis.
When you get such confirmation, you get hot and closer to writing the prose like Carolyn Rose! You have the confidence of sufficient events and all the hidden struggles behind your writing.
;-) -
tool for fluted ends of fonts, serifs (?)
2001-11-21 12:29:22 psheldon [Reply | View]
- (void)drawRect:(NSRect)rect {
//define things centrally and in stages to more easily experiment
/*
remark :
Below, I play with making the radius too short to join to the imaginary guide line. An extension line is drawn to the arc to the imaginary control line.
I wish I could figure the postscript context story, as Next Step probably did a postscript port into their interface and only too well understood that stuff to be able to explain it to us newbies.
Maybe a story about the drafting tools for hot metal type from some sad obsolete soul who can no longer use his once expensive equipment in the age of desktop publishing. The fellow I'm thinking of, his initials BB, geez I'd be scared to bring it up, but Donald Knuth might be completely inaccessible, especially at thanksgiving.
;-)
Maybe safer was someone familiar, not with hot metal, but rather with a font drawing program, friend woman artist.
I tried babbling to her. Out of the blue flew into my mind serifed fonts.
She wasn't hot to it and couldn't respond. I thought to pass the ball to the thread.
I have, however, since had a clear "vision" that this is correct, such a tool is used for the serif.
Zoom up a pdf file and look at a bunch of characters and find examples! Aw heck, consider the letter R with fluted feet, this tool could draw pieces of that.
The arguments of the method were (at first glance) otrociously named, but you can only cram so much into a short space and once you get the feeling of the tool, the words from and to make more sense and don't overload you with pronunciation, spelling or reading and "sort of get out of the way".
;-)
*/
//p1 is my "base left", p2 my "base right"
float x1=0;
float y1=100;
// float x2=80;
// float x2=100;
// float x2=120;
// float x2=150;
// float x2=180;
float x2=10000;
float y2=100;
float xcenter=40;
float ycenter=160;
//note compiler forgave me forgettingt decimal point for float
//float radius=20;// way down from 60 so won't hit, makes straight line then arc to imaginary line
//float radius=30;// progressing up and past 60
//float radius=40;
//float radius=50;
//float radius=55;
//float radius=60;
float radius=120;
//lone point distinguished by not having little rect around it, the end of a NSBezierpath to append to :
NSPoint p1 = NSMakePoint(x1, y1);
//Will make little rects around the end points of the imaginary line :
NSPoint p2 = NSMakePoint(x2, y2);
NSPoint center = NSMakePoint(xcenter, ycenter);
//NSMakeRect(x,y,w,h)
NSRect p2Rect = NSMakeRect(x2-1.0, y2-1.0, 2, 2);
NSRect centerRect = NSMakeRect(xcenter-1.0, ycenter-1.0, 2, 2);
//Objects that when stroked will draw the rects
NSBezierPath * p2Path;
NSBezierPath * centerPath;
//path to augment with arc and arc
NSBezierPath * wall;
NSBezierPath * barrier;
//I added
NSBezierPath * base;
//Want to isolate what does what and couldn't color strokes differently.
//These objects evidentally don't get the color.
[[NSColor blackColor] set];
p2Path = [NSBezierPath bezierPathWithRect:p2Rect];
[p2Path stroke];
centerPath = [NSBezierPath bezierPathWithOvalInRect:centerRect];
[centerPath stroke];
// Constructing the path
//rather constructing a path amongst featuring displaying paths with the method in question
wall = [NSBezierPath bezierPath];
//no path to append to since
//this moves pen with penup from last point of rect around center to start pt p1
[wall moveToPoint:p1];
//center is not center of circle and I go to p2(point on right and marked)
//seems to confirm tangent, but not tangent at point p2, goes beyond.
//how does method determine length of arc?
[wall appendBezierPathWithArcFromPoint:center toPoint:p2 radius:radius];
[wall stroke];
barrier = [NSBezierPath bezierPath];
[barrier moveToPoint:center];
[barrier lineToPoint:p2];
[barrier stroke];
//my additional line
base = [NSBezierPath bezierPath];
[base moveToPoint:p1];
[base lineToPoint:p2];
[base stroke];
}
-
happy you figured it out
2001-11-20 22:29:03 psheldon [Reply | View]
Now, 12:30 A.M. I'm anxious and excited to try out the code and follow your story and see if I can grasp what is going on. I'm sure happy that os 10.1 allows me to connect to my internet computer's lower os 9 appletalk and port over the sample code you give . I shall comment it (take notes on it) and read your story to get the connections going in my head. At first I can be pretty dense, so I better hold off until morning or I'll get in the wrong frame of mind to sleep. But, I'd sure like to peak at it.
Do you know the feeling? -
The plot thickens!
2001-11-21 06:40:57 retro [Reply | View]
Once I get going on something like this, I just don't want to stop. It's going to bug me all day at work today. This function brings back visions of architectural drafting in high school.
An interesting thing I found: When you draw the arc, it conforms to the angle from which you have created. However, if you append to the arc, it does not append to the ever-floating end of the arc, but to the "toPoint:" argument (!). That means the computer will go back and connect itself, thus drawing an ugly line where none originally existed. This intuitively does not make sense, but from a computer programmer's point of view it is necessary.
One of the weaknesses of this function is it's reliance on static points. If you want to make a continuous path, you _have_ to know that your end point is at precisely the point at which the arc becomes tangent to the second line. The second point of tangential contact is equidistant from the apex as the first point of tangential contact. Using manual drafting means, you could discover these points by drawing an arc using the apex as the center point for your compass. You could then find the arc's center by drawing two separate arcs of the desired radial length from each of the two end points, the center being at the intersection point. Then finally, you would draw the arc while carefully erasing all of the other lines.
Unfortunately, we do not have the convenience of a compass to measure where the second point should be. Up to this point it has just been a static point. This is insufficient. We need to find a way to calculate this point and have it change automatically to accommodate the changes in the arc's radius. We need to do the same for the starting point, as I have noticed the arc does not necessarily start at our starting point, but wherever it is mathematically to do so. The starting point, fromPoint and toPoint are used as guides for arc creation but starting or ending points for subsequent path creation. I'll have to think about this one and post more later. -
The plot thickens! So does the fluted R.
2001-11-21 14:20:42 psheldon [Reply | View]
second paragraph :
You are hotter to what your wrote , is ugly line related to the line to the flute on the R end? cf tool for fluted ends of fonts, serifs (?) .
3rd paragraph :
Weakness might be merely for certain values or uses. A tool has a weakness for what you want, you pick up another tool. You're "the man" or artist, you choose, moment by moment. Values change. You want to make some sort of object that draws an R with flutes, you value this, if you want to draw roses, there are other tools.
I think, because I went off on a tangent of finding the postscript context, I have some sort of hindsight you missed.
Does my fluted R vision help you with the conceptualization? -
Absolutely
2001-11-21 05:34:53 retro [Reply | View]
I was up late last night still trying to completely grasp what this function does, and I am doing so right now. I tried, for instance, to make a perfect 100x100 square, and attempted 4 iterations of this command to attempt to draw a flower-like picture. I assumed that the radius of the arcs, 50, would cause a series of half-circles to be made, but I was mistaken.
In fact I believe that the arcs made by this function are actually quite different. The first tangent is made between the initial (appended-to) point and the "fromPoint", the second tangent is made with the "fromPoint" and the "toPoint", as if the two points defined an arbitrarily infinite line for the arc's radius to match properly. You know, its amazing - I didn't fully understand this until I started writing this reply. Trying to explain it to you brought understanding to me.
I have uploaded a picture:
http://homepage.mac.com/abenassi/Images/ArcAndGuide.pct
Here is the new code, which I finally completely grasp:
- (void)drawRect:(NSRect)rect {
#define SIDE_LENGTH 100
float bottom = 100;
float left = 100;
float top = bottom + SIDE_LENGTH;
float right = left + SIDE_LENGTH;
NSPoint bottomLeft = NSMakePoint(left, bottom);
NSPoint bottomRight = NSMakePoint(right, bottom);
NSPoint topRight = NSMakePoint(right, top);
NSBezierPath * arc;
NSBezierPath * guide;
[[NSColor blackColor] set];
// Draw the arc itself
arc = [NSBezierPath bezierPath];
[arc moveToPoint:bottomLeft];
[[NSColor blackColor] set];
[arc appendBezierPathWithArcFromPoint:topRight toPoint:bottomRight radius:60];
[arc stroke];
// Draw the guide from which the computer creates the arc
guide = [NSBezierPath bezierPath];
[guide moveToPoint:bottomLeft];
[guide lineToPoint:topRight];
[guide lineToPoint:bottomRight];
[guide stroke];
} -
Absolutely --- ah I see two tangential
2001-11-21 14:52:20 psheldon [Reply | View]
Paragraph 2 :
I hadn't seen this. Thank you. So, forcing my mind to stretch along my theory as well. You start the leg of the R on each side of the fill and pull the leg with the method to the end of the flute. I think with your direction of the end control, you have two have arguments switched to have it flute each way.
You wrote : "Trying to explain it to you brought understanding to me".
Finding out that writing something to explain to Rockwell Space Division, I was actually explaining it to myself was a life changing experience. In industry, you have those who move up by copying politically correct statements and believing them. People have thought that whenever someone talks to some other, someone is wasting someone else's time because one person must be learning and the other finding him a parasite. Others have thought both people are wasting time. Some supervisors are jealous of other people talking to each other because that takes "power" away from the supervisor and you should report through formal channels of command. Others brow beat you for wasting the valuable supervisors time talking to him. Should should should, all a mockery for job security in Rockwell Space Division. If you can should someone else you are holier than thou in SoCal and that works to get you job security (or, at least, that is the way a senior there explained it to me).
My life changing experience was to go to each individual with one paragraph and ask what was the worst, most incomprehensible, sentence in that paragraph. The people, not a specialist in what I was hot to, found that very easy, even though they were astonished that I would ask them such a question. Everybody in the think tank read one of the paragraphs and picked the awful sentence and I rewrote each of those sentences. I got smart from everyone elses complaints, didn't noticeably bother them because they didn't have to understand anything just say what single sentence they least understood in a single paragraph. I cited them all!
Analogous to Captain Kirk I hope I can continue to believe that "I don't believe in the win lose scenario", though his was the Kobyashi Maroon (sp?) "I don't believe in the no win scenario" cheat.
You might summarize my attempted inspiration with intuition transcends formal channels of communication. Formal channels of communication are from a funny book, "The Psychology of Computer Programming" .
Paragraph 3 :
I saw the picture. You have remembered some lesson I forgot or know how to make a screen shot in os x. Cool. We have a new window on results we can show each other. The picture clearly illustrates the two tangent matching ends of the arc. I found the picture easy to refer to rather than rerunning the code. I then grasped the new concept you found.
Well, now I think I should rest and watch Robin Hood Prince of Thieves with Kevin Costner.
-
I figured it out!
2001-11-20 21:22:43 retro [Reply | View]
I believe I have the solution. The two points passed to this method serve as a guide for an imaginary line. That is, if you drew an infinitely long line which included the two points, that line is your guide. The method attempts to draw an arc with the specified radius from the current bezier path end point to another point somewhere on this line. The arc, as you noted, will always meet at a tangent to the imaginary line, and the direction the arc travels depends on the order of the two points specified. The imaginary line is actually a vector telling the arc as to which direction to travel.
I lack psheldon's linguistic capability to describe this as accurately as I would like, so here is some code to compile. I draw a line between the two guid points to show a segment of the imaginary line. You can see the direction of the arc come into play if you change the order in which you pass the two control points.
- (void)drawRect:(NSRect)rect {
NSPoint p1 = NSMakePoint(0, 100);
NSPoint p2 = NSMakePoint(80, 100);
NSPoint center = NSMakePoint(40, 160);
NSRect p2Rect = NSMakeRect(79, 99, 2, 2);
NSRect centerRect = NSMakeRect(39, 159, 2, 2);
NSBezierPath * p2Path;
NSBezierPath * centerPath;
NSBezierPath * wall;
NSBezierPath * barrier;
[[NSColor blackColor] set];
p2Path = [NSBezierPath bezierPathWithRect:p2Rect];
[p2Path stroke];
centerPath = [NSBezierPath bezierPathWithOvalInRect:centerRect];
[centerPath stroke];
// Constructing the path
wall = [NSBezierPath bezierPath];
[wall moveToPoint:p1];
[wall appendBezierPathWithArcFromPoint:center toPoint:p2 radius:60];
[wall stroke];
barrier = [NSBezierPath bezierPath];
[barrier moveToPoint:center];
[barrier lineToPoint:p2];
[barrier stroke];
}
-
Thanks...
2001-11-20 12:09:30 retro [Reply | View]
I also thought it strange that you would need to tell the initial point from which to append a path. The documentation is poor on this method, and it is a shame that this is the first method in NSBezierPath that draws anything. People like me who are trying to start out and wrap our minds around this class are naturally going to try to use this method first. I wish I was at home so that I could try to confirm and confer our findings for this method. Later tonight I will give it a whirl. -
Question about method in NSBezierPath
2001-11-18 18:01:13 psheldon [Reply | View]
Will try to construct example and confirm your observation on method messing up, but right now I'm zonked from a night of meteor chasing and observing. Having no doppler radar with me in my car, driving far from an internet connection while all around me people were sleeping, I had to make hypotheses alone by myself about fog and how to get out of it on rustic 380 Texas.
;-)
-
sorry didn't detab
2001-11-08 12:43:54 psheldon [Reply | View]
So, you have to recognize my paragraphs by the end indents, not the normal begin indents.
-
pretty print (Q)
2001-11-08 12:39:54 psheldon [Reply | View]
As I read, I simply paste in from the column the code rather than type it. I then "pretty print it", that is put in white space and indents, to break it into digestable thought chunks. Pretty printing can be a very mechanical thing and, I believe, that mechanical thing doesn't really help me to understand. I might like a rudimentary ap to pretty print c's "{}" 's for me by indenting the nested ones more . I've seen such automatic parentheses emerging in the beta versions of what is now called livemath. In contrast, maple does not have a pretty printer. ETH Modula had a syntax directed editor which "apriori" pretty printed as you constructed stuff, but Apple or the column affords the stubs which, on pasting from Mike's column, I must pretty print aposteriori.
I recall a pretty printer long ago, but can't get a better lead on finding it. Since Applescript has a scriptable text editor, I suspect that someone with parser experience, could have made a "pretty printer" in Applescript (Jon Pugh?). Applescript itself automatically pretty prints, so I suspect a died in the wool applescripter wouldn't worry about it. Parsers are written with recursive calls. Anybody who has done the humungous task of making a compiler might have rolled their own pretty printer to make their own work surveyable.
-
oop building from frameworks
2001-11-08 12:35:01 psheldon [Reply | View]
I decided, as I went along, to make laboratory research notes in my project which I would then paste into a topic in a thread. So, I added a file, of type empty, to my project, we might call it a tabla rasa or empty canvas, I called it scratch!
When I put into the project the new file subclass to nsview, CurvesView, Apple put in the stubs for me to fill in with some comments where I was to fill in.
I observed afresh methods only appearing in implementation with minus signs prefacing them. I got out my ObjC.pdf and saw the minus sign meant it was an instance method rather than a class method. I wondered why these instance methods only appeared in implementation ".m" files. I believe this was because they were overrides. I thought there must be a terse way of phrasing a fundamental thing about oop, "overrides of a subclass to a fundamental class afforded by apple or next step in a framework which aren't seen by someone through his interface, will instead only be seen by the parent class through its interface. In this manner, we build upon rather than through".
I wish I could write this more tersely or cleverly, because I think such a statement would be a turning point in research notetaking on what oop building from frameworks means.










Thank you to Mike and O'Reilly for a great series on Cocoa programming in X. Keep it up! (please?) :/