Re: cocoa app from scratch
Re: cocoa app from scratch
- Subject: Re: cocoa app from scratch
- From: Matt Jarjoura <email@hidden>
- Date: Mon, 19 Jul 2004 14:45:35 -0400
What I haven't heard from anyone is that if you really want to do GUI
programming w/o the advantages of IB, then use Carbon. Carbon is far
better suited for doing event handing and GUI coding because the API
is structured more logically for manually coding. (Since it comes
from the orignal way to write Mac OS apps)
Cocoa is really one big NSView and NSController system and you are
going to have to understand the Window Manager/Quartz technology
pretty thouroughly. For instance, IB can sheild the developer from
having to work with the flipped coordinate system.
Third, if you cannot find documentation on Apple's website, read the
header files. Sometimes, (and maybe a habit from Mac OS X 10.0 days)
the engineers write the help inside of them before the tech pub guys
get a chance to write formal docs.
Lastly, don't be afraid of IB, most if not all of the new 1.0 apps out
there are being written in Cocoa. Take it in small chunks if you have
to, but once you get your 1.0 app out there, then start exploring
Cocoa's internals and creating your own custom views. That'd be my
advice.
-Matt
On Mon, 19 Jul 2004 11:33:29 +0200, Ihar 'Philips' Filipau
<email@hidden> wrote:
>
Mark A. Stratman wrote:
>
> I can understand hand-coding all your GUI controls for the sake of
>
> learning. Don't let me or anyone else discourage you if that's your
>
> goal. For any other purpose though, programmatically creating your
>
> entire GUI is almost *always* a very bad thing to do, and a nightmare
>
> for maintenance.
>
>
I have recalled another point of why nightmare AKA all dynamic GUIs
>
are used, especially in large projects. It is too good point to not to
>
re-iterate it on list.
>
>
I'll be short.
>
>
Source Code Management Systems: CVS, Subversion, BK, VSS, whatever.
>
>
Non-human-readable == non-maintenable.
>
You cannot review it.
>
You cannot check what was modified.
>
If you have more than one person working on GUI - thing can go wrong
>
too easy.
>
>
I know examples of big projects when people where dropping GUI
>
builders precisely for this reason. Or better cases were developping
>
tools to convert GUI templates to/from human-readable/understandable
>
form - so it can be checked-in, reviewed, diffed and patched later.
>
>
FYI.
>
>
P.S. Ordered "Programming Cocoa" by Scott Anguish (Choosen thickest book
>
available on Amazon with "Cocoa" in its name. 1272 pages. If turns out
>
to be bad - I can use it as a stand.).
>
Now waiting for delivery... ;-)
>
>
>
>
--
>
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
>
-- _ _ _
>
"In the event of a percieved failing of the project |_|*|_|
>
leadership #debian is empowered to take drastic and |_|_|*|
>
decisive action to correct the failing, including by |*|*|*|
>
not limited to expelling officials, apointing new
>
officials and generally abusing power"
>
-- proposed amendment to Debian Constitution
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
>
>
--
Matt Jarjoura
:: They say life is like a bowl of cherries, eat it up! ::
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.