Life after QuickDraw using .r
slashlos
files over but stuck just how. I've a bunch of 'pict' and 'cicn' which
Xcode seems to read just fine, has a pre-built target to a .rsrc file,
but if QD is going away, just what Quartz mechanism should be used to
access these resources?
I've read thru the Quartz API for QD but don't seen anything detailing
how to migrate .r files and their usage, in the post QD world. Anyone
gone this way before?
--
/los "I was a teenage net-random"
------------------------------------------------------------------------
Opinions expressed here are mine and not necessarily those of my employer!
------------------------------------------------------------------------
Jens Ayton
>
> Well, with [recent to me] deprecation, I need to move older Rez (.r)
> files over but stuck just how. I've a bunch of 'pict' and 'cicn' which
> Xcode seems to read just fine, has a pre-built target to a .rsrc file,
> but if QD is going away, just what Quartz mechanism should be used to
> access these resources?
>
> I've read thru the Quartz API for QD but don't seen anything detailing
> how to migrate .r files and their usage, in the post QD world. Anyone
> gone this way before?
For better or worse, resource forks are effectively deprecated too. The
modern way of doing things is to store individual image files in your
application bundle's Resources directory, and access them through
CFBundle/NSBundle.
--
Jens Ayton
slashlos
as {file}.pict, add them into the project and move them in Xcode into a
new bundle. Unlike a NIB bundle, this resource bundle is nothing more
than a folder which'll contains my various .pict, etc files I can then load?
Simon Slavin
<oQp_g.20526$E02....@newsb.telia.net>:
> slashlos:
>
> > Well, with [recent to me] deprecation, I need to move older Rez (.r)
> > files over but stuck just how. I've a bunch of 'pict' and 'cicn' which
> > Xcode seems to read just fine, has a pre-built target to a .rsrc file,
> > but if QD is going away, just what Quartz mechanism should be used to
> > access these resources?
None. Resource files just aren't the Quartz way.
> > I've read thru the Quartz API for QD but don't seen anything detailing
> > how to migrate .r files and their usage, in the post QD world. Anyone
> > gone this way before?
There's no reasonable way to do it using Quartz/Cocoa. The simplest way
to do the conversion is to use the old-style environment to turn your .r
files into whatever kind of resources they represent, save those as
individual files, then shift to the OS X environment and turn those
resources into new-style individual files which don't have resource forks:
.png files, OS X icon files, etc..
So you may be facing a week or so where you do no programming at all,
simply spend the time in various utility programs (or simply doing
screendumps) converting your assets from one format to another. Thank
goodness for Preview's wonderful conversion abilities, and if you have
sound resources it might be worth buying QuickTime Pro.
> For better or worse, resource forks are effectively deprecated too. The
> modern way of doing things is to store individual image files in your
> application bundle's Resources directory, and access them through
> CFBundle/NSBundle.
Yep. And since you're dealing with one type of migration anyway, you
might as well start using Cocoa and go all the way to NSBundle. It does
make things extremely simple when you can load an image from your bundle
and display it in a view using just two lines of code (or one really long
one).
Simon.
--
http://www.hearsay.demon.co.uk
slashlos
...
> Yep. And since you're dealing with one type of migration anyway, you
> might as well start using Cocoa and go all the way to NSBundle. It does
> make things extremely simple when you can load an image from your bundle
> and display it in a view using just two lines of code (or one really long
> one).
>
> Simon.
Thanks, sigh!:-(
I have many sequences like this
RGB{Fore|Back}Color(&some_color);
MoveTo(x,y);
SetRect(left,top,right,bottom);
DrawString or PlotCIcon or EraseRect etc.
(this code is circa 1984, btw)
In eyeing a sample, it seems it (PathDemo, the only one I've found so
far) relies solely on a sort of callback into drawRect method of the
custom view class demoView, whereas my needs are more directed. How /
can this 'rect' [as seen in this example] be exposed to other classes
and still be 'Cocoa' or should I rethink totally the graphics
interaction [so long as I'm making a pile of to-dos before I can get
back to being productive]?
slashlos
started. Thanks to all!
Simon Slavin
> I have many sequences like this
>
> RGB{Fore|Back}Color(&some_color);
> MoveTo(x,y);
> SetRect(left,top,right,bottom);
> DrawString or PlotCIcon or EraseRect etc.
>
> (this code is circa 1984, btw)
>
> In eyeing a sample, it seems it (PathDemo, the only one I've found so
> far) relies solely on a sort of callback into drawRect method of the
> custom view class demoView, whereas my needs are more directed. How
> can this 'rect' [as seen in this example] be exposed to other classes
> and still be 'Cocoa' or should I rethink totally the graphics
> interaction [so long as I'm making a pile of to-dos before I can get
> back to being productive]?
The equivalent of an image which needs to run arbitrary code when it
draws is an NSView. You define an NSView in the position you want. When
the operating system decides the view needs redrawing it calls your
drawRect method. You can put what you like in that method.
An NSView has
a setting which allows it to be hidden. So to effectively 'EraseRect' all
you need is to hide the NSView you used to render the image.
There's a
special case of NSView which is NSImageView. That one, you just feed with
an NSImage and when its drawRect method gets called it just renders the
image. Unless, of course, it's hidden in which case it does
nothing.
Going any further into your needs would require high-level
understanding of your application. If it has just one image on the
display at once (which may change from image to image or position to
position) you could define one NSView at the beginning and just move it
about, load different images into it, and hide/show it. If it needs to
display many images at the same time, things might get more
complicated.
Good luck with it.
Simon.
--
http://www.hearsay.demon.co.uk
slashlos
> Going any further into your needs would require high-level
> understanding of your application. If it has just one image on the
> display at once (which may change from image to image or position to
> position) you could define one NSView at the beginning and just move it
> about, load different images into it, and hide/show it. If it needs to
> display many images at the same time, things might get more
> complicated.
>
> Good luck with it.
>
> Simon.
replace the oval being drawn, with an icon, pict or tiff image. The
image's placement before was based on a point based on pixels, which now
is based on a floating point or relative to the housing 'rect'. This I
think I understand. In my application there's a crude animation where
the image is moved or altered but not in a random fashion as in the
sample. Historically this was done by erasing where it was, and
redrawing it somewhere else. This needs to be rethought in the quartz
way of doing things, but I'm making progress, albeit slowly...:-) Thanks!
Ingemar
Why all the agony? Why don't you just keep using the resource files and be
happy? Data fork resource files work perfectly fine in Mach-O. Since they
are much easier to manage than NIB files (automatically available), I'd
switch to NIB only for user interface items that I really need, and that
are best made there, but storing PICTs in a resource file is just fine by
Mach-O.
Or have I missed any news? Apple aren't going to pull the plug on PICT and
Resource Manager support in Carbon, are they? In their current
not-invented-here-trend they depriciate everything which is "old
Apple", but that doesn't necessarily mean that it goes away.
* posted via http://MacErudite.com
* please report abuse to http://xinbox.com/mymac
Ben Artin
ing...@ragnemalm-dot-se.no-spam.invalid (Ingemar) wrote:
> Or have I missed any news? Apple aren't going to pull the plug on PICT and
> Resource Manager support in Carbon, are they? In their current
> not-invented-here-trend they depriciate everything which is "old
> Apple", but that doesn't necessarily mean that it goes away.
Actually, some time after they deprecate and API, they do remove it. A reason to
keep up with deprecation of APIs is that if you do it now (when they are merely
deprecated) you can release a new app to the users at your convenience, but if
you wait (until the APIs stop working), you end up having to release under
pressure because the app doesn't work in some way.
Ben
--
If this message helped you, consider buying an item
from my wish list: <http://artins.org/ben/wishlist>
I changed my name: <http://periodic-kingdom.org/People/NameChange.php>
Ingemar
I am not sure about that. Removing PICT support would only be stupid,
leaving thousands of users with files they can't open. Removing support
for resources would be equally meaningless, they are part of Mach-O so why
take them away? They may remove things when they get hard to re-implement
(like Classic support under Intel). QuickDraw might seem awkward in a
resolution-independent environment, but if it is removed, I bet there will
be a third-party replacement. Remember QuickDraw 3D.
The very first case of "depriciation" I ever saw, the first time
I ever heard the word, about some AWT feature in Java, is about a feature
that is still working. It didn't go away.
Patrick Machielse
> > Actually, some time after they deprecate and API, they do remove it.
>
> The very first case of "depriciation" I ever saw, the first time
> I ever heard the word, about some AWT feature in Java, is about a feature
> that is still working. It didn't go away.
The word is 'deprecation' ('decpreciation' is from economics) ;-)
Don't count on deprecated API _not_ being removed. Apple _will_ take the
opportunity offered by some technical changes to 'clean house'. One such
change you already mentioned is the move to Intel. Another oportunity
will be the move of all frameworks over to 64 bit. Deprecated API won't
necessarilly be removed from the 32 bit world, but they certainly won't
be ported to 64 bit.
Be prepared.
patrick
Ben Artin
nor...@mail.invalid (Patrick Machielse) wrote:
> Don't count on deprecated API _not_ being removed. Apple _will_ take the
> opportunity offered by some technical changes to 'clean house'. One such
> change you already mentioned is the move to Intel. Another oportunity
> will be the move of all frameworks over to 64 bit. Deprecated API won't
> necessarilly be removed from the 32 bit world, but they certainly won't
> be ported to 64 bit.
In particular, there will be no 64-bit QuickDraw.