PDA

View Full Version : Wwdc 2007



Chilton
06-11-2007, 01:59 PM
(title should be WWDC 2007)

http://www.macrumors.com/

Thoughts?

-Chilton

bsales
06-11-2007, 02:36 PM
Lightwave as a 64bit Mac app running in Leopard will be fantastic! Is this the sort of comment you were looking for, or did you want commentary on Apple's announcments?

cresshead
06-11-2007, 03:11 PM
was disapointed...no new imac's...no hardware at all....and osx was demo'd ''again''....that dratted ipooo delayed devlopment of osx and so delayed the new imac's....baaah humbug!

RonGC
06-11-2007, 03:37 PM
Yeah, a new iMac quad 3ghz 30"Lcd display with 8 gig ram installed for $1999.00 would have made a nice announcement LOL.

Just have to wait a bit, they are constantly updating hardware these days.

Ron

Phil
06-12-2007, 12:35 AM
Leopard is certainly shiny, but the limited scope of TimeMachine is irritating. The requirement to have a second disk is fine for desktops, but for portables it severely reduces the usefulness of the feature. I'd hoped this was going to mean a versioning filesystem, but it seems like it is just a pretty interface on a scheduled backup tool.

The menu bar is semi-transparent and the dock has been adjusted. Neither are particularly significant or helpful. Being able to autohide the menu bar would be nice, especially since I already do this with the dock (and thus don't care about the cosmetic changes). It's change without real reason.

The stacks and Spaces both look helpful, although I have yet to see people become really comfortable with virtual desktops in practice....I'm not sure how well this is going to work.

It wasn't clear whether the preview system would be extensible. An obvious thing here would be whether Modeler/Layout could deliver a custom preview of an object/scene to allow the preview system to be useful. Without that extensibility, I'm struggling to see the use.

I'd have liked to see MacFUSE implemented directly, or some equivalent. It's the only way we'll get official support for writing to non-standard filesystems (e.g. NTFS).

I'd also have liked to see OS X adjusted to allow for appending to folders rather than replacing them when the destination folder already exists - this is my biggest annoyance under OS X and leads me to mammoth sessions with ChronoSync to work around it.

On-disk compression (like NTFS provides) would have been sweet, especially given the relatively small disk capacities on portables.

It looks shiny, and I expect I'll pick up the upgrade, but I'm not completely convinced. From the developer side, I can't comment.

Lightwolf
06-12-2007, 01:39 AM
Pretty much with Phil here.

The new Finder looks glitzy, but still lacks a lot of functionality that I'd exppect (i.e. the option to directly edit or type in a apth). That may go completely against the design philisophy. I'm just note sure about the "iTunes for Files" thing ;)
Basically none of the new stuff on the surface they've showed really Wows me, but having a native 64bit OS on the Mac side finally is a good thing.
Not sure about what changed under the hood, but I suppose I'll find out soon enough (I'll get an intel Mac as soon as Leopard is out... and I hope they'll have something between the MacPro and the iMacs by then - decently fast, extensible and 64bit compatible, but no built-in display).

Cheers,
Mike

BazC
06-12-2007, 01:48 AM
Like the others I'm not too impressed with what I've seen, fancy transparency and reflection effects presumably use more system resources and serve absolutely no purpose.

iChat theater could be very useful for working with clients/agents/other designers over the internet.

If the preview feature can be made to work with LW and other 3d files it will be FANTASTIC!

I got the impression that Apple were cooking up something clever with GFX cards/OGL but I haven't heard anything yet. I kinda hoped they'd figured some way to make multiple low end cards work together to equate to a higher end card. So I could add another 256mb card to my existing one (cheaply) rather than dumping my present card and replacing it with an expensive 512mb card. Ah well!

Obviously having a fully 64bit OS at last will be great. Not sure I'll be rushing to upgrade though, I can't afford enough RAM to take advantage of it really, not for a while anyway.

So what do you think Chilton? You probably have a deeper understanding of the possibilities offered by Leopard than most of us, how is this going to benefit LW?

BazC
06-12-2007, 02:32 AM
If rumours are to be believed t seems like Leopard will support 128bit ZFS file system (http://www.macworld.com/news/2007/06/08/zfs/index.php) which if I understand what I've read could be more interesting than all this other stuff put together!

Seems like a ZFS disk has the potential to hold much more data than the same size HFS+ disk. Data is accessed faster and is less prone to corruption.

It also seems like booting from a ZFS disk is very difficult so first implementation is likely to be used for secondary HDs.

Any thoughts Chilton?

Phil
06-12-2007, 03:05 AM
I'd also be happier if they suggested that Leopard will bring a hotkey combination to restore minimised windows from the dock. Command-Tab, but no window restoration, gets old pretty fast. :(

LW_Will
06-12-2007, 03:06 AM
ZFS also removes limits for storage... or at least puts them way off... heat death of the universe or something... so, that should last for a year or three...

The Pixel Club boyz were dscussing it on MacBreak Tech, ep 2. If you want the episodes, its here... feed://feeds.pixelcorps.com/feeds/macbreak_tech.xml

They also talk about scary RAID, redundant redundant RAID, and not so scary RAID...

I'm writing on SAFARI for XP, by the way... ;-)

cresshead
06-12-2007, 04:48 AM
yeah a really cool filing system...iphone really killed development schedule of their
computers this year...that'll be 12 month's since their last update proper on imac
macbook mac pro except for 8 core chip add on which someone had up n running last november and mac mini and looks as though the current mac mini [non 64bit chip] has it's days numbered
by how mr jobs described their computer lineup.

no real point releasing new hardware to run on old software [osx] when they've been talking up the new O/S for over a year and have demo'd it twice now...time machine looked great the first time round...this time lacked any punch cos of the development overrun induced by iphone....i hope the iphone launch goes smoooth in 17 days time...wouldn't want apple push back new pc's anylonger.

don't know about you but the demo felt like a re run of the last one to me...

eblu
06-12-2007, 07:23 AM
hmmm... this WWDC was about the stuff under the hood. i didn't see one knock em dead feature on the front end, just a lot of elegance and polish. But the real winners are what you can't see.

64 bit = true
core animation seems like a winner, even if the candy dev make w/ it will get old really fast, now almost anyone can dev a lightning fast 3d compositor!
the stacks bit in the dock seems interesting, though I wish they allowed that tech to work across the finder... no more impossible to display folders filled with an image seq.
safari on windows is odd.
xcode 2 is a MAJOR killer app, make no mistake, its almost like apple just announced that they'd make mac dev's years 3 weeks longer than every body else's and that they worked it out so that it was all vacation time. I've completely derailed all of my little dev projects so that I can do them (completely from scratch) in leopard. No more retains!!!!

what else... widgets... meh... translucent menu... double meh... angular beveled and reflective dock... over it.

the new mail is great.

quicklook, the new icon architecture (chilton... please take a look at Apple's new push in that area... its indicative of a minor shift and you guys will get caught out yet again) its interesting where Apple seems to be going with this.

the enhancements to .mac are mildly interesting. though not widely touted, .mac seems to be getting the attention it needs.

all in all, I found This keynote to be more entertainment than information, with the real Stars of the show in-between the lines. I suspect that was on purpose. Leopard is a HUGE release, with a lot of architectural changes that are subtle, difficult to have accomplished, and worth everything they put into it.

Lightwolf
06-12-2007, 07:40 AM
xcode 2 is a MAJOR killer app,
Erm, XCode 3, right?

Are there any news on that on the website?

Cheers,
Mike

eblu
06-12-2007, 08:06 AM
right. typing(or thinking) before caffeine = bad thing.

RonGC
06-12-2007, 12:09 PM
I personally like the new finder, with ability to scan through hundreds or thousands of video files and visually see the one i want, then open it, is worth a lot for me when working on a video project.

It may not be useful much to LW users but to videographers, content creators, graphic designers etc. it just makes it a lot easier to find and get at a certain file. And not just on one machine but across a network of machines. This means a lot of saved time hunting down that obscure file the old way.

Plus with keyed searches it is easy to home in on a half remembered video file.

Zfs if it is a go in Leopard will be a major plus.

Ron

eblu
06-12-2007, 01:28 PM
Erm, XCode 3, right?

Are there any news on that on the website?

Cheers,
Mike

hmmm... some. nothing deep. you have to be ahh... well connected in order to know whats actually going on under the hood.

there are some very general descriptions. you will have the ability to start a project in OBJC 2.0 or 1.0. 2.0 has "modern garbage collection" and several very cool advancements, mostly to tie in Core data and scripting closer to the os.

Lightwolf
06-12-2007, 03:30 PM
there are some very general descriptions. you will have the ability to start a project in OBJC 2.0 or 1.0. 2.0 has "modern garbage collection" and several very cool advancements, mostly to tie in Core data and scripting closer to the os.
Ah, allright then. Well, since I'm a cross platform guy focussed on C++ that doesn't really affect me.
It would be nice to have closer ties to Cocoa from C++, but I doubt that'll ever make it the light of the day...

Cheers,
Mike

Weepul
06-12-2007, 06:50 PM
Hm, we got to see 10 out of 300 features and only two of them were things we hadn't heard about before (and then, only in part). Uh, Steve? What exactly were you presenting? Hyping things with "secret features" only works so long before we need to hear about a couple of them - and they really need to amaze us - to keep up the excitement.

64-bit's potentially going to be awesome (and it's about time), though I get the feeling it might be another way for plugins to be incompatible on a Mac (first it was just being a Mac, then it's having to be Universal, and next...32/64?) At least it ought to be possible to run a 32-bit version of LW seamlessly.

What was up with Steve saying this was going to be the world's first mainstream 64-bit OS? I seem to remember the validity of that statement hinging on the semantics of exactly how he phrased it, which I can't remember...


iChat theater could be very useful for working with clients/agents/other designers over the internet.
Yeah, but what happened to the VNC-like ability that was previously announced? (Apparently it's still in there, but it's odd that they don't even mention it.)


I'm just note sure about the "iTunes for Files" thing ;)
Geez, let me tell you, that was exactly the wrong comparison to make from my standpoint. Learn from Microsoft's mistakes, Apple, and don't make your OS's interface like some other app. I want my OS to look like an OS, not a web browser or music player... Even in Tiger, every single Finder window on my Mac has been toggled to the plain old-style window mode (don't remember it's real name) and it annoys me to no end when the OS "forgets" sometimes when opening windows from a different place (eg. reveal location from a search) and that certain windows just plain can't be saved that way (Trash and the "My Computer"-esque directory list). The button is still there on the Leopard windows...here's hoping the alternate window mode's still there.

eblu
06-12-2007, 10:12 PM
Ah, allright then. Well, since I'm a cross platform guy focussed on C++ that doesn't really affect me.
It would be nice to have closer ties to Cocoa from C++, but I doubt that'll ever make it the light of the day...

Cheers,
Mike

umm... that came with the LAST version of XCode (heh. Xcode 2, this OBJC 2 and Xcode 3 crap does me in.).
its called Objective C++ the crazy engineers over at apple merged C++ and ObjC. sooooo... you can work in cocoa with C++, its been about 1.5 years now.

the whole thing is pretty cool. you can write your logic in pure C++, or Objective C++. pure C++ can be a unix tool, a faceless app (service or a server of some sort) or carbon based. Objective C++ is Cocoa, With the C++ extensions of C welded right onto it.

so depending upon who you are, just in C++ you have HUGE choices in app design. I suggest for you a path that makes your cross platform development work for you.
dev all of your logic in C++,
bring it whole hog into Xcode,
then turn it into a unix tool, or several unix tools (depending upon its complexity) this is trivial compared to trying to shoehorn your whole app into a cocoa wrapper.
then write an app that mediates the communication between your unix tools and your mac interface.

Apple provides a few VERY powerful tools in cocoa for just this kind of app. (NSThread is one) and if your wondering if that kind of high level communication is reasonable for a graphics heavy app... Shake does it that way.

but umm... I digress.

anyway. Thats what I'm doing with screamernet. but I'm waiting for leopard. I hate retain loops.

Haven1000
06-13-2007, 01:50 AM
quicklook, the new icon architecture (chilton... please take a look at Apple's new push in that area... its indicative of a minor shift and you guys will get caught out yet again) its interesting where Apple seems to be going with this.

:i_agree:

The way I read it is you just need to write a plugin for quicklook to read the file so no preview has to be imbedded into the original file or separate cache , is this the case?

Lightwolf
06-13-2007, 03:04 AM
its called Objective C++ the crazy engineers over at apple merged C++ and ObjC. sooooo... you can work in cocoa with C++, its been about 1.5 years now.

the whole thing is pretty cool. you can write your logic in pure C++, or Objective C++. pure C++ can be a unix tool, a faceless app (service or a server of some sort) or carbon based. Objective C++ is Cocoa, With the C++ extensions of C welded right onto it.

Yeah, I had a look at that... but it still retains the Objective part in the equation... which kind of sucks. As soon as you get to directly interface with the OS on the Mac you're either faced with legacy Pascal style or Obj-C - not what I'd call developer friendly if you come from any other OS (i.e. unix or windows). File handling being an example that is extremely horrid.
I dunno, whenever I look at the APIs I'm not surprised they came up with something as horrible as AppleScript as well ;)
So basically, I try to stick to the Posix layer if I can (which has issues as well though).

Cheers,
Mike

Chilton
06-13-2007, 06:09 AM
Howdy,

Regarding my WWDC question, I'm not fishing for any particular comments, just curious.

Leopard is the future, and it's a really nice, shiny, reflective future. And no, LightWave will not be left behind on this one. No developer in their right mind would! But our exact plans for Leopard are a tightly guarded secret. So while we do have specific Leopard centric plans, I don't think that should surprise anyone.

But I'm still not at liberty to divulge them.

eblu
06-13-2007, 07:34 AM
:i_agree:

The way I read it is you just need to write a plugin for quicklook to read the file so no preview has to be imbedded into the original file or separate cache , is this the case?

i "think" that we are seeing the proverbial tip of the ice berg.
Apple has done this before, they put some new unassuming feature out and mildly suggest how they want you to use it (assuming you are a dev), they give dozens of tips and examples, but they never really advertise it. then it catches on with users... hitting some sort of usage threshold and Apple unveils that it is the center of a major new feature, or minor paradigm shift, that if you supported it early on... gives you support without any changes to your code. Quicklook is tied a bit too closely to the new "find paradigm" that seems to be taking over our OS interfaces. Something is going on with QuickLook, its got to be the foundation for something extra ordinary. I think Apple is trying to do away with file icons altogether, no document icons at all, every icon generated on the fly, from the content of the file, with a built in viewer that runs IN the os, for every file. They won't tell us in advance, and it won't happen unless we as a whole accept the minor changes from Quicklook in the first place, but... personally... I'd love to see Lightwave in the front rather than the rear on just one of these things.

Haven1000
06-13-2007, 07:45 AM
i "think" that we are seeing the proverbial tip of the ice berg.
Apple has done this before, they put some new unassuming feature out and mildly suggest how they want you to use it (assuming you are a dev), they give dozens of tips and examples, but they never really advertise it. then it catches on with users... hitting some sort of usage threshold and Apple unveils that it is the center of a major new feature, or minor paradigm shift, that if you supported it early on... gives you support without any changes to your code. Quicklook is tied a bit too closely to the new "find paradigm" that seems to be taking over our OS interfaces. Something is going on with QuickLook, its got to be the foundation for something extra ordinary. I think Apple is trying to do away with file icons altogether, no document icons at all, every icon generated on the fly, from the content of the file, with a built in viewer that runs IN the os, for every file. They won't tell us in advance, and it won't happen unless we as a whole accept the minor changes from Quicklook in the first place, but... personally... I'd love to see Lightwave in the front rather than the rear on just one of these things.

Once again I concur. I wouldn't be surprised if we see the touch screen stuff that their doing with the iphone to make it into the "conventional desktops" with Quicklook being the centre of it all. The first thing I thought of when I saw Qucklook was Minority Report:D

eblu
06-13-2007, 07:59 AM
Yeah, I had a look at that... but it still retains the Objective part in the equation... which kind of sucks. As soon as you get to directly interface with the OS on the Mac you're either faced with legacy Pascal style or Obj-C - not what I'd call developer friendly if you come from any other OS (i.e. unix or windows). File handling being an example that is extremely horrid.
I dunno, whenever I look at the APIs I'm not surprised they came up with something as horrible as AppleScript as well ;)
So basically, I try to stick to the Posix layer if I can (which has issues as well though).

Cheers,
Mike

hmmm... mike I just don't understand. there is so much room here for misinterpretation, and subjective veiwpoints, so pls forgive if we differ in opinion. it has always been my experience that anyone who learned to code with a windows box, they tend to be very close minded when it comes to the mac os. I keep hearing... "too hard" "non intuitive" "not dev friendly"

Unix coders Never say that. they say things like: "its odd in some places, but it makes sense if you look at the whole thing."

I've lived with both OBJ c and the plumbing of Os X for several years now. I am by no means a great coder, but I have a very good high level understanding of the architecture of the os, and some very practical experience in some very key areas. Believe me, Apple did not go out of its way to make it difficult for you to do what you want in its programming environs. I would say that they did exactly the opposite.

when Apple makes a new feature for the os, they tend to make it in 2 parts. first they make a simple/powerful foundation set of classes, in what you'd call POSIX. they test this in house and in the wild for a while, and then they make an OBJ-C wrapper. A wrapper simply bridges the Posix LIBS into Cocoa (obj-C or OBJ-C++) What this does for the programmer is that it allows him/her the same level of control, in the high level OBJ-C/C++ AND in the POSIX stuff. its the same libs. This makes support easier for apple, lessens the chance of bugs, increases the utility of the feature, and allows the dev to make a choice that isn't contingent on features. All of the same features are available in the Foundation classes (POSIX) that are availible in Cocoa (OBJ-C/C++).

each time I see how they've applied this design style to the os, I am more and more impressed. this is the only way to develop a modern OS. I've had a taste of what it is like to try to bridge the gap, I've looked into the things I would have to learn in order to dev on windows, and let me tell you... I've said some of the same things about that, that I have heard from windows devs going to the mac. But I can accept that its all just learning curve stuff, and that it is entirely manageable. I don't think anyone who refuses to learn some Mac-centric programming basics will ever be a good developer on the mac. Its never going to do things like windows, and thats WHY people use it.

so uhh... file handling? the way it refers to files? reads/writes to them? the way you get a file requester? I never found it to be problematic. maybe I just don't see it the way you do.

Lightwolf
06-13-2007, 08:07 AM
hmmm... mike I just don't understand. there is so much room here for misinterpretation, and subjective veiwpoints, so pls forgive if we differ in opinion. it has always been my experience that anyone who learned to code with a windows box, they tend to be very close minded when it comes to the mac os. I keep hearing... "too hard" "non intuitive" "not dev friendly"
Well, I started on a C=64 if that is any help to you ;) And I'd prefer to develop on an Oberon system, but that really is no use, is it? ;)


so uhh... file handling? the way it refers to files? reads/writes to them? the way you get a file requester? I never found it to be problematic. maybe I just don't see it the way you do.
Probably not. On Win32 (which I have just as much experience with as Cocoa/Carbon - since I try to stay as OS neutral as I can) I just find it to be way easier to just open a file requester, get the filename and be gone with it. Don't ask me how many obscure conversion routines I have to call in Carbon to get a simple path out of a CRef whatever construct.

Basically, whenever I need to access the OS (which I try not to do directly as much as possible), on windows I look up the API docs, use it and be done. One the Mac I look up the API docs, then get some weird datatypes that need to be handled using other functionality that I need to look up again etc... and some time later I might get what I need.

Basic task: Get a posix file name from a file requester.

Now all of this may make sense if you stick to the platform... if you don't it is a pain.

Cheers,
Mike

Chilton
06-13-2007, 08:08 AM
Hi,


The way I read it is you just need to write a plugin for quicklook to read the file so no preview has to be imbedded into the original file or separate cache , is this the case?

(my apologies of I did post this somewhere else, I thought I did, but can't find it now)

QL is an extension of the file browser that we've (developers) been asking for since around the mid 90's. I know it was a planned feature for Copland, and was partially possible back when QD3D was king.

It's good to see it finally making its way into the OS.

-Chilton

Chilton
06-13-2007, 08:12 AM
Hi,


Well, I started on a C=64 if that is any help to you ;) And I'd prefer to develop on an Oberon system, but that really is no use, is it? ;)


Oberon... I loved it when it first came out. But the novelty wore off pretty quick for me. They thought 'too different'.



Probably not. On Win32 (which I have just as much experience with as Cocoa/Carbon - since I try to stay as OS neutral as I can) I just find it to be way easier to just open a file requester, get the filename and be gone with it. Don't ask me how many obscure conversion routines I have to call in Carbon to get a simple path out of a CRef whatever construct.


This isn't easy, I'll say that much. And in Cocoa (well, Appkit in Cocoa), you're encouraged not to touch file requesters directly, letting the frameworks handle getting the file, you only play with the data. It's a different approach, but probably not a bad one.

I was playing with file requesters earlier today--I feel your pain ;-)

-Chilton

Lightwolf
06-13-2007, 08:19 AM
This isn't easy, I'll say that much. And in Cocoa (well, Appkit in Cocoa), you're encouraged not to touch file requesters directly, letting the frameworks handle getting the file, you only play with the data. It's a different approach, but probably not a bad one.

Oh, absolutely. And it works if you never intend to leave the platform.


I was playing with file requesters earlier today--I feel your pain ;-)

Hehe, which is why I got into the OS API in the first place, I needed more functionality than the LW SDK provides currently.

Shall I mention HFS+ vs. Posix paths as well? ;)

Cheers,
Mike

Chilton
06-13-2007, 08:42 AM
Hi Eblu,



...each time I see how they've applied this design style to the os, I am more and more impressed. this is the only way to develop a modern OS


I completely agree. Every WWDC things look like they're getting better, especially for Cocoa developers. The presence of Safari on Windows certainly makes the Dharma project look real.

Perhaps this time next year we'll be discussing a new cross-platform LightWave written entirely in Cocoa ;-)

-Chilton

eblu
06-13-2007, 09:00 AM
Oh, absolutely. And it works if you never intend to leave the platform.

Hehe, which is why I got into the OS API in the first place, I needed more functionality than the LW SDK provides currently.

Shall I mention HFS+ vs. Posix paths as well? ;)

Cheers,
Mike

I'm missing something.
in cocoa. its ONE LINE OF CODE to launch a file requester.
what coems back is a nice Object which you can then write
ONE MORE LINE OF CODE in order to get to the data directly.

in carbon (which is HIGHLY discouraged, by APPLE these days, esp for file access) it IS a nightmare. Basically If your using Carbon to launch a file requester, and you are not adobe (with billions and billions of lines of legacy code) then your not doing it right, you've made things obscenely difficult for yourself, and you are the people apple really wants to bring into the fold.

open Xcode 2. launch the documentation. go down the tree to :
ADC Home > Reference Library > Guides > Cocoa > File Management >

read.

you'll find both low level approaches and high level approaches to file requesters. you'll wonder how you ever got anything done using the cracked up Carbon Libs for this.

I strongly suggest you use the high level approach. they have a very good example that lays everything out for you.

Oh and Chilton, if you NEED NEED NEED to customize the file requester window in any way, there are some options in the NSOpenPanel object, and some freaking AWESOME approaches that depend on the objective nature of Obj-C itself. I STRONGLY suggest talking with an Apple engineer if you really need to do this, and I Strenuously Suggest you buy the guy/girl a beer or two and tell them your problems, I've heard rumors that those engineers basically fix it for you.

But, after having run up against the same problem quite a few times, I have always found that the default file requester has been more flexible than I initially gave it credit for being.

PS. NSString... the Cocoa class which encapsulates strings... has several very awesome utilities for turning Strings to POSIX paths. you'll need this to turn what you get from the file requester into what YOU need Mike. the file requester returns an array of NSStrings, called filenames.

Lightwolf
06-13-2007, 09:23 AM
I'm missing something.
in cocoa. its ONE LINE OF CODE to launch a file requester.
what coems back is a nice Object which you can then write
ONE MORE LINE OF CODE in order to get to the data directly.

D'oh... launching it is a line of code in any OS ;)
However, I'm still at 48 lines vs. 70 lines of code for my complete class (W32 vs. Carbon).

I'll gladly mail you my source to check out. (honestly, if there is a better way to do it I'll gladly pick it up and learn).


in carbon (which is HIGHLY discouraged, by APPLE these days, esp for file access) it IS a nightmare. Basically If your using Carbon to launch a file requester, and you are not adobe (with billions and billions of lines of legacy code) then your not doing it right, you've made things obscenely difficult for yourself, and you are the people apple really wants to bring into the fold.

open Xcode 2. launch the documentation. go down the tree to :
ADC Home > Reference Library > Guides > Cocoa > File Management >

read.

I read every part on the SDK docs I found on the topic (including exhaustive searches), both Carbon and Cocoa. (I've spent 10 minutes looking up the API call in Win32 vs. at least 4 hours until I got all the pieces I need for Carbon).
Of course, LW currently is Carbon based, so how can I use Cocoa?
Also, I need to do this from within a C++ class, and I needed it to be done quickly without reading the docs on half of the APIs.
Did I mention cross platform? That is CodeWarrior, GCC as well as MSVC, both binary types for LW included.
And I'd like the return to be a vanilla c style string at least, so I can use it with my "normal" code as well.


PS. NSString... the Cocoa class which encapsulates strings... has several very awesome utilities for turning Strings to POSIX paths. you'll need this to turn what you get from the file requester into what YOU need Mike. the file requester returns an array of NSStrings, called filenames.
Hm, so I can just use Obj-C classes in C++ code then?

Cheers,
Mike

Chilton
06-13-2007, 09:32 AM
Hi Eblu,


I'm missing something.
in cocoa. its ONE LINE OF CODE to launch a file requester.


That's the problem--LW is not a Cocoa app at this time (this is not a statement of future direction, just pointing out the current status). I am mixing in Cocoa more and more, but right now our file I/O is not at a state where we can use the Cocoa method of working with them.

And mixing the two makes it more complicated than just doing it in Carbon.



in carbon (which is HIGHLY discouraged, by APPLE these days, esp for file access) it IS a nightmare.

It's not that bad, it's just under-documented in parts.


I STRONGLY suggest talking with an Apple engineer if you really need to do this, and I Strenuously Suggest you buy the guy/girl a beer or two and tell them your problems, I've heard rumors that those engineers basically fix it for you.

Well, we have all the help we could want from Apple on this front, it's just a matter of time and energy.

-Chilton

Lightwolf
06-13-2007, 09:35 AM
It's not that bad, it's just under-documented in parts.

I'm glad it isn't just me then... Documentation does seem sparse in places indeed.

Cheers,
Mike

Scazzino
06-13-2007, 09:36 AM
Well, we have all the help we could want from Apple on this front, it's just a matter of time and energy.

Cool, does this mean file requesters will work with the content directory the way LW needs it to, as discussed elsewhere? ;)

RonGC
06-13-2007, 11:42 AM
Its official Leopard will ship with NFS+ and ZFS file systems, with NFS+ being the default.

Ron

Lightwolf
06-13-2007, 11:44 AM
Its official Leopard will ship with NFS+ and ZFS file systems, with NFS+ being the default.

Isn't ZFS read only and command line only?

Cheers,
Mike

eblu
06-13-2007, 12:13 PM
Hm, so I can just use Obj-C classes in C++ code then?


in a word... YES. you are beginning to see it. its the biggest strength of OS X... since OBJ-C and C++ are C variants, Apple was able to easily get them into the exact same environment. For clarity's sake they have their own mind share space, but they can and should interact.

but, lets back up a sec. I think I see your BIG problem... CodeWarrior.

you can't get anything done on the mac in codeWarrior. I'm sorry. its been dead for about 4 years now. I know that you are stuck with it for the moment. I know that. I understand that you need to follow along w/ the dev tools of LW in order to make things that get along w/ LW. I get it. I know the reality.

But you are basically using tech that is 11 years behind where the mac os is right now. no wonder its a pain in the ***.

carbon on XCode is insanely easier than Carbon on CodeWarrior, and frankly, its not even necessary to stop there.
remember the promise of PowerPlant? yeah, in Xcode its finally delivered, with cocoa.

Dump CodeWarrior. You'll only be happier in the long run. granted you can't do that right now, but sometime soon... you will be able to.

Now about the logistics of making Cocoa calls in Carbon Coding... I've never gone that way, but I was made to think that if you link to the Cocoa libs, you can make Cocoa calls.
PERIOD.
and sometimes all you really want is something pretty basic anyway, and its already available in the Core Foundation. No need to link anything to get that. Its already available to carbon. Core foundation is the basis for everything in the os. Cocoa is built on top of it , and Carbon is slowly becoming it (OpenGL is considered part of CF, as is Quicktime). its IS C. its logical, and its very low level in the os. ie: no more pascal weirdness.

I humbly suggest however, a different approach for you mike.
dev your logic engine as agnostic as possible, leaving out the OS level interaction. When its comes time to port to OSX, start a Cocoa App (OBJ-C++) in Xcode.
make the UI in Interface builder (assuming of course it HAS an interface), and import all of your C++ files into the project. hook them up. going what would seem to you, as backwards. from here all the correct libs are already linked, and you will be able to leverage OBJ-C for UI, and stick with C/C++ for your Agnostic code base.

granted, not knowing anything about what you are actually doing, I may be steering you wrong, for instance you may want to do it on the command line in which case... you don't need carbon or Cocoa.

re: the docs.
I've had a lot of trouble w/ the docs too, but for the most part its with the organization, and my assumptions. I usually find what I need under really odd headings, or I realize some distance down the path that I had assumed something was more complicated than it really was, and I was looking for something that I didn't need. That said, they need WAY more examples in the ref docs, and they need to give a MUCH clearer overview. In any case, after you get a good hold on the overview, traversing the docs seems to get easier, and the language they use has more actual meaning.

RonGC
06-13-2007, 12:18 PM
Isn't ZFS read only and command line only?

Cheers,
Mike

Have to wait for more info from Apple to see how they plan to implement ZFS.

Ron

Scazzino
06-13-2007, 12:20 PM
Have to wait for more info from Apple to see how they plan to implement ZFS.

Ron

Here's what I heard (read)...
http://www.macobserver.com/article/2007/06/13.2.shtml

Lightwolf
06-13-2007, 12:24 PM
I humbly suggest however, a different approach for you mike.
dev your logic engine as agnostic as possible, leaving out the OS level interaction. When its comes time to port to OSX, start a Cocoa App (OBJ-C++) in Xcode.
make the UI in Interface builder (assuming of course it HAS an interface), and import all of your C++ files into the project. hook them up. going what would seem to you, as backwards. from here all the correct libs are already linked, and you will be able to leverage OBJ-C for UI, and stick with C/C++ for your Agnostic code base.

This is way overboard. I've got a C++ based wrapper for the LW SDK... and all I want is a native file requester (well, I do have it working for a long time now, but I remember the pain).

My basic question concerning C++ was: If I have a C++ class, compiled in a .cpp file, will that be able to directly use Objective C classes, or is there a need to wrap?

Cheers,
Mike

Edit: I'm also not much of a fan of building interfaces using a visual designer, but for GUIs (outside of LW) I use wxwidgets anyhow...

Lightwolf
06-13-2007, 12:27 PM
in a word... YES. you are beginning to see it.
Actually, re-reading your post... I've again come to the conclusion that for an OS specific noob like me the Win API is just too easy ;) It may be old and dated... but it works without having to consider tons of stuff...

Cheers,
Mike

RonGC
06-13-2007, 12:47 PM
Here is a link to 10 reasons to install ZFS

http://www.tech-recipes.com/rx/1446/zfs_ten_reasons_to_reformat_your_hard_drives

Interesting read.

Ron

eblu
06-13-2007, 01:56 PM
Actually, re-reading your post... I've again come to the conclusion that for an OS specific noob like me the Win API is just too easy ;) It may be old and dated... but it works without having to consider tons of stuff...

Cheers,
Mike

the only problem with old and dated, is that (in OS X) it will go away, and your stuff will be broken. but hey, thats in the future ;) why worry about it now?

btw: it looks like you Do have to wrap Cocoa calls from C++, which doesn't appear to be the preferred way of dealing with that kind of thing. its in the docs with an elaborate guide, and 1 example. Its so much easier to make a Cocoa App, and do all of the hard stuff in C/C++.

eblu
06-13-2007, 01:59 PM
Here is a link to 10 reasons to install ZFS

http://www.tech-recipes.com/rx/1446/zfs_ten_reasons_to_reformat_your_hard_drives

Interesting read.

Ron

its great, no doubt about it. Apple isn't convinced though. ZFS does seem to fit Perfectly with the XRaid and the XSan though. One wonders if Apple is eyeing up ZFS for its prosumer level San-ish hardware lines.

Lightwolf
06-13-2007, 02:26 PM
the only problem with old and dated, is that (in OS X) it will go away, and your stuff will be broken. but hey, thats in the future ;) why worry about it now?
Sorry, I meant that by looking at the win32 API... which is ages old (NT 3.51 at least) but still works.
Of course NT is moving toward more proprietary stuff as well... basically .NET and managed code.
Between a rock (Obj-C) and a hard place (.NET) I suppose... ;)

Cheers,
Mike

j__
06-13-2007, 05:53 PM
Well from what I can see Leopard is probably the worst looking Mac OS in the history of OS X. It looks horrible, it's a mess of trite 'lifestyle' gizmos, XP-like drudge and more half-baked interface themes. It's interesting Apple have to actually dig through their own fan speculation sites to come up with junk like 'stacks' aka piles and so on.

Chilton: "Leopard is the future, and it's a really nice, shiny, reflective future."

Even some of the most mainstream, some of the most tame, of Apple sites are describing Leopard features as a 'polished turd', others as 'boredom and disappointment', although one fan I saw was saying "I'm really upset that Apple didn't make ZFS the default FS', yeah you have to wonder about people like that.

OS X started loosing the plot with Tiger. Although a lot of people believe way before that. In any event, Apple is no longer a serious researcher into human interface and OS development, but a pretty hollow superfluous eye candy, gizmo and widget vendor to appeal to the lowest common denominator. As I've said before, and I'll say it again: best not to follow it there Chilton.

Chilton: "LightWave will not be left behind on this one."

Left behind in what way ? Adding pretty reflections across Lightwave as you drag a panel ? Creating a giant slow animation as you open a scene, integrating ichat backdrops into LW ?

I suppose you could create a plug-in for the view thing or whatever it's called, that previews LWOs in the Finder, but let's be frank, who works like that? and a 2MB LWO with plenty of images is slow enough to load into Modeler never mind creating a thumbnail or interactive 3d view of it in the Finder on the fly.

Chilton: "...while we do have specific Leopard centric plans"

A dedicated Time Machine just for LW ? I'm only joking Chilton.

I don't know every thing that is under the hood in 10.5, but outside of say 64 bit addressing (which is already in Tiger) or any back-end X code stuff, you know, I hope you don't have any Leopard centric plans, and I hope no serious developer of serious software (i.e non 'lifestyle' software) has any overtly 'Leopard-centric' plans either.

RonGC
06-13-2007, 07:33 PM
I don't think ZFS would be possible as the default filesystem, As far as i know it can't be used on the startup disk,

However like it or not, leopard is the next OSX, so get used to it cause it ain't going away anytime soon. Apple can't please everyone, would be stupid even to try, in that direction lies madness LOL.

Everyone is entitled to their opinion. If you like it fine, if you hate it thats fine too, just please do not expect your opinion to outweigh that of others.

Ron

Lightwolf
06-14-2007, 02:26 AM
I don't think ZFS would be possible as the default filesystem,

Not if your engineers are busy trying to get a phone to work - SCNR ;)

Cheers,
Mike

RonGC
06-14-2007, 10:13 AM
Not if your engineers are busy trying to get a phone to work - SCNR ;)

Cheers,
Mike

True LOL but even Sun, who developed Zetta File System, to this day is having a lot of trouble getting it to work properly on the boot disk.

Ron

RonGC
06-14-2007, 10:32 AM
Heres some news from Luxology. Modo 301 to use bonjour for network rendering.

"With Bonjour support, modo users will be able to create a network renderfarm without having to set up complicated grid computing software, according to Luxology. All Macs and PCs on the network are automatically detected by modo 301, and up to 50 nodes can operate as a render farm. Rendering tasks will be automatically parceled out to machines that are in a "ready-to-render" mode; visual feedback is provided on which parts of the image are being rendered. Modo 301 will use network rendering either to compute single high-res print images or to render out entire animation sequences."

Interesting stuff.

Ron

jeremyhardin
06-20-2007, 07:59 AM
It seems likely to me that Leopard is a move toward a shift in interfaces in general. And iPhone is a testing ground for the new technology.

I suspect that the cover flow fnder is going to be multi-touch friendly and that the interface is slowly being converted to that mindset. So when bobcat comes out (or whatever) with a multi-touch interface, the interaction won't be a huge relearning paradigm shift. It'll be the same as it was in leopard, only more flashy-touchy.

Just some speculation.

Chilton
06-20-2007, 08:49 AM
Just some speculation.

Microsoft's Surface, iPhone, multi-touch trackpads are already on all portable Macs, and Apple is stressing resolution independence to all of its developers (so apps look right at any zoom factor).

Something's up.

-Chilton

jeremyhardin
06-20-2007, 08:59 AM
interesting. And my tiger is already very zoom-friendly using control + mouse scroll. So I'm all the time zooming into this or that in my OS or on a webpage. i could see that changing very easily to the two-finger zoom instead of the current key combination. and perhaps evolving to refine quality at different zoom levels.

interesting indeed.

Scazzino
06-20-2007, 10:10 AM
interesting. And my tiger is already very zoom-friendly using control + mouse scroll. So I'm all the time zooming into this or that in my OS or on a webpage. i could see that changing very easily to the two-finger zoom instead of the current key combination. and perhaps evolving to refine quality at different zoom levels.

interesting indeed.

Hey, cool, I didn't know you could do that! It works across both screens too, zooming the whole desktop... :thumbsup:

Chilton
06-20-2007, 10:12 AM
It is control+two-finger zoom on a MacBook... it's like they're training us.

I am not code monkey!

-Chilton

Scazzino
06-20-2007, 10:13 AM
That's different than resolution independent zooming though, it seems to just dump the the desktop screen buffer to an image and then zoom the image. It's still neat though... ;)

Scazzino
06-20-2007, 10:16 AM
It'd be nice if they also scaled the mouse tracking when zooming in this way though... When zoomed in tight, it's almost impossible to move around since each twitch of the mouse flings you all over the place... ;)

Chilton
06-20-2007, 10:46 AM
Hi Mike,

This feature has been in OSX since the early days, but was slightly difficult to find. You can change what you're referring to though, in the Universal Access preferences. Set it to only move the screen when you near an edge.

One side effect of this is that you'll become addicted to it, then find yourself using it late at night as your vision is fading, to compensate.

-Chilton

jeremyhardin
06-20-2007, 10:49 AM
One side effect of this is that you'll become addicted to it, then find yourself using it late at night as your vision is fading, to compensate.

haha. nail on the head.

Scazzino
06-20-2007, 11:17 AM
Hi Mike,

This feature has been in OSX since the early days, but was slightly difficult to find. You can change what you're referring to though, in the Universal Access preferences. Set it to only move the screen when you near an edge.

One side effect of this is that you'll become addicted to it, then find yourself using it late at night as your vision is fading, to compensate.

-Chilton

True, come to think of it, I think you could even do something similar in classic Mac OS's Universal Access control panel (or whatever it was called if different) too... But I could never remember the keystrokes, so it wasn't something I used... having it tied to control-scroll wheel is front and center so it's much easier to remember and actually use.

I checked out the movement settings but the problem with the "only at edge" setting is that I have lots of screen real-estate to cover 1920x1200 & 1280x1024 which makes it a hassle to have to move all the way to the edge... particularly horizontally... I'd much prefer if there were an option to have the mouse speed/distance scale down as the image scales up so the overall movement remained proportional...

:D

RonGC
06-20-2007, 11:40 AM
As we rapidly move down the road towards the Neuromancer, Cyber Cowboy holographic interface. Flying through a graphic cyber interface.

Color is important as we are 60% visual and as we get into spinning, with cover-flow through our touch and holographic interfaces, color of items will be how our eyes will spot the file we want as the files flow by.

Bright colors attract our eyes as they move, mono-colors when in motion blur into one object, too easy to lose where we are in the interface.

Looking forward to more of these style interfaces, freedom to fly. LOL

Ron

Weepul
06-20-2007, 06:29 PM
Hi Mike,

This feature has been in OSX since the early days, but was slightly difficult to find. You can change what you're referring to though, in the Universal Access preferences. Set it to only move the screen when you near an edge.

One side effect of this is that you'll become addicted to it, then find yourself using it late at night as your vision is fading, to compensate.

-Chilton
Hey Chilton, when LightWave is the forefront app, the rate of zooming when scrolling is significantly reduced; where a flick of my scroll wheel would take me way in when using Safari, in LightWave, the same action barely zooms it at all. Any chance of rectifying this?

If it makes any difference, I use a Microsoft IntelliMouse Explorer with their accompanying software.

Chilton
06-20-2007, 06:44 PM
Hi,

Assuming you're using the CFM version, it might be a CFM version issue. If you're using the Universal Binary version of LightWave, ask in the UB Workshop and I'll look into it there.

But either way, I'll take a look.

-Chilton

Weepul
06-20-2007, 06:48 PM
Assuming you're using the CFM version, it might be a CFM version issue. If you're using the Universal Binary version of LightWave, ask in the UB Workshop and I'll look into it there.
As of the last versions I downloaded, 9.2 (CFM) release and 9.2 GM2 (UB), both exhibit that behavior. So, where do I post when it's cross-version? :D

Chilton
06-20-2007, 07:35 PM
UB Workshop

However, I do not believe we have a 9.2 GM2 UB.

-Chilton

Weepul
06-22-2007, 12:34 AM
Well, it was whichever version was released concurrently with the CFM GM2.

I'll cross-post over there. ;)