Ok...I'm fûckin' sick and tired of hearing this 'there should be no differences between a well-written cocoa app and a well-written carbon one'-bullshit. In case you're fückin' blind, you'll realize that cocoa will have features such as drawers that aren't available with the carbon API.
</strong><hr></blockquote>
And the reverse is true. There are a number of Carbon features that Cocoa cannot access. So the two APIs are roughly even.
[quote]Originally posted by kim kap sol:
<strong>
And the truth is...and I know it's hard to swallow...nobody's able to write a good carbon app. That's right mofo! Nobody 'cept maybe Andrew Welch aka moki from Ambrosia and those crazy guys at Panic. All carbon ports lick my nutz. You lick my nutz. And you're stupid if you think carbon is ever gonna produce something worthy of OS X.
Shaddup! All of youz b30tchz! Cocoa is a god send in terms of creating an easy and nice-looking GUI and is a time-saver if you want to implement simple things such as scrollwheel support and services.
</strong><hr></blockquote>
But you *can* do all of these things in Carbon. They may require extra work, but it will achieve the same goal in the end.
[quote]Originally posted by kim kap sol:
<strong>
There will always be a difference between carbon and cocoa apps...because it's easier to develop a cocoa app and developers are lazy wankers that won't put the effort in making a good carbon app that takes full advantage of OS X since it would require extra code.
</strong><hr></blockquote>
*I* am not a "lazy wanker." I have spent hours trying to make my *Carbon* app (see above) look and behave just like a Cocoa app. Heck, I've even spent money on it! And I'm giving away my app!
[quote]Originally posted by kim kap sol:
<strong>
Agree or disagree...I don't care. Cocoa 0wnz j00 and it's no joke.
</strong><hr></blockquote>
And you would be wrong.
PS-If you want anyone to take you seriously, you need to learn how to write in proper english. Some of us find it-gasp!-easier to read a post written properly, And some of us-gasp!-take a well written post more seriously than one written in god-knows-what.
And the reverse is true. There are a number of Carbon features that Cocoa cannot access. So the two APIs are roughly even.
</strong>
<hr></blockquote>
Oh reaaaally? Like which ones genius boy!? Back up you claims, or nobody will be able to *you* seriously even if you programmed Cranberry, a decent app (albeit with shitty non-Aqua toolbar icons).
[quote]
<strong>
But you *can* do all of these things in Carbon. They may require extra work, but it will achieve the same goal in the end.
</strong>
<hr></blockquote>
Yes, yes, yes...selective quoting will get you nowhere. I mentioned that all of this can be done but with 'extra work'...and most developers aren't ready to put this extra work in. Except a handful of developers...including you.
I'm sad and hurt that you felt like the target of my rantings. Haven't you heard that there's 'exceptions to [most] rules?' You, Andrew Welch and the boys at Panic are this exception.
[quote]
<strong>
*I* am not a "lazy wanker." I have spent hours trying to make my *Carbon* app (see above) look and behave just like a Cocoa app. Heck, I've even spent money on it! And I'm giving away my app!
</strong>
<hr></blockquote>
Good for you...I hope there are more good carbon developers like you out there. So far there aren't many. You're a respectable developer...but alas, you can't say your app behaves like a cocoa app. You'd be wrong.
[quote]
<strong>
And you would be wrong.
PS-If you want anyone to take you seriously, you need to learn how to write in proper english. Some of us find it-gasp!-easier to read a post written properly, And some of us-gasp!-take a well written post more seriously than one written in god-knows-what.</strong><hr></blockquote>
Nah, I wouldn't be wrong...99.9% of the developers won't put the required effort into a carbon app to make them on par with cocoa apps. Therefore carbon sucks.
Obviously you did take my poorly written post seriously if you took the time to dissect it bit by bit. Thank you for proving yourself wrong.
Oh reaaaally? Like which ones genius boy!? Back up you claims, or nobody will be able to *you* seriously even if you programmed Cranberry, a decent app (albeit with shitty non-Aqua toolbar icons).
</strong><hr></blockquote>
Whoa, I take my comment back...I actually downloaded your app and tried it out.
1st mistake...REALBasic. LOL!
Here's a list of things missing in your app that I've discovered in the first 30 seconds of testing:
No scrollwheel support.
A half-assed sheet implementation (sometimes save invokes a sheet...sometimes it doesn't.)
No customizable toolbar (or is that a cocoa-only feature...the Finder has it but is it a hack?)
No services support.
Here's a list of missing features that aren't your fault because they're cocoa-only features:
Drawers.
And here are non carbon-vs-cocoa-related issues:
Here's a bug I saw in the first 5 seconds of scrolling some Marathon scripts:
Text occasionally scrolls out of the text field. Screenshot to come.
Things I'm not too impressed with:
Your sucktacular application icon and the toolbar icons.
Sorry, bub, your app doesn't pass the test...and I haven't even tested it fully. I'd probably find a lot more problems and carbonish pet peeves if I took any more time.
[ 03-24-2002: Message edited by: kim kap sol ]</p>
Whoa, I take my comment back...I actually downloaded your app and tried it out.
1st mistake...REALBasic. LOL!
</strong><hr></blockquote>
And would you please explain why REALbasic is a mistake?
[quote]Originally posted by kim kap sol:
<strong>
Here's a list of things missing in your app that I've discovered in the first 30 seconds of testing:
No scrollwheel support.
</strong><hr></blockquote>
I don't have a scrollwheel mouse. So I haven't had a chance to implement it. And plase remember that the application is in BETA testing: some things may not be there or work as expected.
[quote]Originally posted by kim kap sol:
<strong>
A half-assed sheet implementation (sometimes save invokes a sheet...sometimes it doesn't.)
</strong><hr></blockquote>
Could you explain further?
[quote]Originally posted by kim kap sol:
<strong>
No customizable toolbar (or is that a cocoa-only feature...the Finder has it but is it a hack?)
</strong><hr></blockquote>
It is a hack in the finder, and in my app, there is no need for customization (what you see is what you get).
[quote]Originally posted by kim kap sol:
<strong>
No services support.
</strong><hr></blockquote>
See above - It's a BETA!
[quote]Originally posted by kim kap sol:
<strong>
Here's a list of missing features that aren't your fault because they're cocoa-only features:
Drawers.
</strong><hr></blockquote>
A short list that is irrelevant because I have no need for drawers. And many people dislike them, myself included.
[quote]Originally posted by kim kap sol:
<strong>
And here are non carbon-vs-cocoa-related issues:
Here's a bug I saw in the first 5 seconds of scrolling some Marathon scripts:
Text occasionally scrolls out of the text field. Screenshot to come.
</strong><hr></blockquote>
Don't bother. Its a known bug.
[quote]Originally posted by kim kap sol:
<strong>
Things I'm not too impressed with:
Your sucktacular application icon and the toolbar icons.
</strong><hr></blockquote>
That would be an OPINION, and therefore carries no weight.
[quote]Originally posted by kim kap sol:
<strong>
Sorry, bub, your app doesn't pass the test...and I haven't even tested it fully. I'd probably find a lot more problems and carbonish pet peeves if I took any more time.
</strong><hr></blockquote>
So, are you saying that every Cocoa app is perfect because it is Cocoa, and that Carbon is bad because it is Carbon? I'd bet that I could find a bunch of problems with Cocoa apps to criticize.
I don't have a scrollwheel mouse. So I haven't had a chance to implement it. And plase remember that the application is in BETA testing: some things may not be there or work as expected.
</strong><hr></blockquote>
Typical answer...
[quote]
<strong>
Could you explain further?
</strong><hr></blockquote>
Quitting the app through the menu or through cmd-q will make the save sheet drop down if you have some unsaved changes. Using 'Save' or 'Save As' from the menu will not make a save sheet drop but instead make the save dialog box pop up.
[quote]
<strong>
It is a hack in the finder, and in my app, there is no need for customization (what you see is what you get).
</strong><hr></blockquote>
Another typical answer to defend carbon..."I don't need to customize my toolbar, so you don't either."
So here we have the first reason why carbon is crap...uncustomizable toolbar. While I don't much care if a toolbar is customizable or not...I do care about consistency. Carbon and cocoa apps do not feel or act the same way (they might to the untrained eye I guess).
[quote]
<strong>
See above - It's a BETA!
</strong><hr></blockquote>
Yes, yes, yes, I see what you're doing here. Because it's beta you're exempted from any of the comments I make about your application.
Don't announce your program as a model carbon app if it's not...I don't care if it's beta or not.
[quote]
<strong>
A short list that is irrelevant because I have no need for drawers. And many people dislike them, myself included.
</strong><hr></blockquote>
I agree, this one is a gray area...if not implemented properly, drawers can be a pain more than anything else. Although I can think of some ideas of what you could have done with drawers if your app was cocoa. If you want my ideas, say so...I'll send you an email and some GUI mockups (although I bet you don't want my ideas now that I've ridiculed your app. It's up to you if you want feedback and ideas.)
[quote]
<strong>
That would be an OPINION, and therefore carries no weight.
</strong><hr></blockquote>
You're right...it's an opinion and it carries no weight. But I do enjoy consistency with the Aqua GUI and icons that don't follow the guidelines stick out like a sore thumb.
[quote]
<strong>
So, are you saying that every Cocoa app is perfect because it is Cocoa, and that Carbon is bad because it is Carbon? I'd bet that I could find a bunch of problems with Cocoa apps to criticize.
</strong><hr></blockquote>
Nope...not saying that at all. Just saying that cocoa is better for the developer and the end-user.
Better for the developer since you inherit behaviors/features for free such as a scrollwheel support, services, customizable toolbars, sheets etc...
Better for the end-user because consistency is where it's at. Having scrollwheel support in on app and lack of scrollwheel support in another is no good. Having customizable toolbars in one app and lack of customizable toolbars in another is no good. Having services in one app...well you get the picture right?
You say that you haven't put in scrollwheel support because you don't have a scrollwheel mouse. Fine. But if you were programming in cocoa, you wouldn't need a scrollwheel mouse to test out scrollwheel support because the scrollwheel support would be there already.
Anyways...my advice to you is: Don't announce your program as a model carbon app if it isn't. I understand it's still in beta but you have to realize that you asked for it by telling me that your app is a great carbon app that couldn't be differentiated from a cocoa app.
[ 03-24-2002: Message edited by: kim kap sol ]</p>
Anyways...my advice to you is: Don't announce your program as a model carbon app if it isn't. I understand it's still in beta but you have to realize that you asked for it by telling me that your app is a great carbon app that couldn't be differentiated from a cocoa app.</strong><hr></blockquote>
OK, well let's end this discussion (It was fun, wasn't it?). I would like to hear your suggestions; it will make Cranberry a better Mac OS X citizen.
A few notes:
The way that I am implementing toolbars is with a 3rd party module that actually draws everything like a Cocoa app does. It does not access the NSToolbar class (It's not accessable to Carbon apps, IIRC). The customize sheet would be extremely difficult to do as the sheet must come out of the toolbar and not the title bar, and I don't believe that to be possible in Carbon.
I thought REALbasic had Scrollwheel support, I'll double check that. And if it doesn't, I know of another way to do that. To be honest, you are the first person to even make me think about it.
Save sheets shouldn't be too hard to do.
I apprecate your poiting these things out, as I want my app to be a first class citizen in Mac OS X.
<strong>PS-I would still like to hear how RB is a mistake </strong><hr></blockquote>Most people have a hatred for RB apps because most of them are crap. Just look at the comments for some of the uglier RB apps on VersionTracker! Whoo-boy! RB has a history of major, annoying GUI bugs with OSX including the rainbow-colored text (which I think was fixed) and the mis-aligned background "pinstripes" behind widgets like checkboxes, text fields, and the like. Plus, many RB apps seem extraordinarily l-a-r-g-e and s-l-o-w.
Of course, that doesn't mean *all* RealBasic apps are inherently bad. Though, there have been SO MANY bad apps, it's hard to shake the reputation.
<strong>Most people have a hatred for RB apps because most of them are crap. Just look at the comments for some of the uglier RB apps on VersionTracker! Whoo-boy! RB has a history of major, annoying GUI bugs with OSX including the rainbow-colored text (which I think was fixed) and the mis-aligned background "pinstripes" behind widgets like checkboxes, text fields, and the like. Plus, many RB apps seem extraordinarily l-a-r-g-e and s-l-o-w.
Of course, that doesn't mean *all* RealBasic apps are inherently bad. Though, there have been SO MANY bad apps, it's hard to shake the reputation.</strong><hr></blockquote>
The Rainbow colored text issue was fixed 6 months ago, and the misaligned pin stripes issue has been fixed in the 4.5 alphas. The reason that took so long is that it required a complete rewrite of how the interface was handled to support a parent-child relationship between, say, a button and a tab panel.
As far as the slowness issue, REAL Software is writing a new compiler (which is now available in the form of RBScript) that will be included into REALbasic as the main compiler in the near future (probably 5.0).
I don't think the Finder problem is related to any kernel mutexes.
- Unix file systems store each directory in a regular file, containing the names of the files in that directory and their inodes. If you want to read file specific information, you have to iterate over all these files (inodes). The OSX Finder provides such information (modification date, size etc.), thus a lot of inodes have to be read if you do a directory listing. However, this is of course not done with only one low-level system call but with at least one for each file (I don't know OSX's vfs, but it will ultimately come down to some sort of lookup/get call). So, if you have to go through a lot of files, you can easily stop at every point and switch to another thread, leaving the Finder fully responsive.
- Even if you're right with your funnel theory, connecting to an iDisk should not block local disk operations or even general event handling in the Finder since I don't think that reading a local directory or selecting a folder does actually perform network system calls, do you?
- I also don't think that connecting to an iDisk is only one BLOCKING sys call, and iDisk navigation even less. Therefore you should be able to connect and navigate several iDisks in parallel without having to wait for each operation to fully complete. (Webdav uses tcp, which means that all connect/send/receive operations can be done asynchronously.)
Conclusion: The Finder does use multiple threads for file copying etc. but doesn't do so for event handling and navigation(dir-listing). I call this a very bad design. IMHO, locks may indeed be the problem if you want to do several dn lookups at the same time or somethink similar, but not if you want to work with a big/remote directory and always have a completely unresponsive Finder.
<strong>Most people have a hatred for RB apps because most of them are crap. </strong><hr></blockquote>Monica is great; although it'd be greater if it re-connected when a download is interrupted as well as the OS 9 version did (I have a feeling it's Apple's fault, though)
I clearly said that I don't think all RealBasic programs are bad. I use several StimpSoft (RIP) apps regularly and they're all written in RB. I simply wanted to state the simple truth that RB has a bad reputation because of the shabby apps out there that were written by amateur programmers. At least 2/3 of the RB apps I download go straight to the trash because they're just ugly, disorganized, and slow. This isn't entirely RB's fault but much of the programmers.
As far as the slowness issue, REAL Software is writing a new compiler (which is now available in the form of RBScript) that will be included into REALbasic as the main compiler in the near future (probably 5.0).
</strong><hr></blockquote>
They also said that this would be incorporated into version 4.x, but as we all know, it wasn't.
I'm not sure what version RealBasic is up to, or what version I last bought was either, but I do know that I don't like the fact that they upgrade all the time, and charge you an arm, and a leg for it. I've paid those dicks probably $700 I could have bought codewarrior for that, and been much happier. Plus + It's for shit anyway. S-L-O-W-! I think it's a dead end programming compared to all the latest options there are for the Mac platform now that OS 10 is comming of age.
-------THE FINDER------
As has been previously stated:
The Finder is not a Cabon Port of a legacy finder to OS 10.
I've opened mine up a few times with different tools, and I think if you open it using resorcerer for X it says "Fake Finder" right there.
I think of it as what pins the dock down in place at it's starting point, and all apps float in to the dock from there. Apple could have called it anything. I think they used the finder to make you more comfortable. Sometimes I thnk it lags because some of the XML utilization in the dock could be optimized better, but I'm not sure realy because I'm not all that familiar with XML yet so I'm essentaily talkin' out of my ass.
Comments
Thanks for the serious responses, AirSluf.
<strong>
Ok...I'm fûckin' sick and tired of hearing this 'there should be no differences between a well-written cocoa app and a well-written carbon one'-bullshit. In case you're fückin' blind, you'll realize that cocoa will have features such as drawers that aren't available with the carbon API.
</strong><hr></blockquote>
And the reverse is true. There are a number of Carbon features that Cocoa cannot access. So the two APIs are roughly even.
[quote]Originally posted by kim kap sol:
<strong>
And the truth is...and I know it's hard to swallow...nobody's able to write a good carbon app. That's right mofo! Nobody 'cept maybe Andrew Welch aka moki from Ambrosia and those crazy guys at Panic. All carbon ports lick my nutz. You lick my nutz. And you're stupid if you think carbon is ever gonna produce something worthy of OS X.
</strong><hr></blockquote>
Ahem, *I* write a good Carbon app.
<a href="http://homepage.mac.com/mbenonis/cranberry/"; target="_blank">http://homepage.mac.com/mbenonis/cranberry/</a>;
[quote]Originally posted by kim kap sol:
<strong>
Shaddup! All of youz b30tchz! Cocoa is a god send in terms of creating an easy and nice-looking GUI and is a time-saver if you want to implement simple things such as scrollwheel support and services.
</strong><hr></blockquote>
But you *can* do all of these things in Carbon. They may require extra work, but it will achieve the same goal in the end.
[quote]Originally posted by kim kap sol:
<strong>
There will always be a difference between carbon and cocoa apps...because it's easier to develop a cocoa app and developers are lazy wankers that won't put the effort in making a good carbon app that takes full advantage of OS X since it would require extra code.
</strong><hr></blockquote>
*I* am not a "lazy wanker." I have spent hours trying to make my *Carbon* app (see above) look and behave just like a Cocoa app. Heck, I've even spent money on it! And I'm giving away my app!
[quote]Originally posted by kim kap sol:
<strong>
Agree or disagree...I don't care. Cocoa 0wnz j00 and it's no joke.
</strong><hr></blockquote>
And you would be wrong.
PS-If you want anyone to take you seriously, you need to learn how to write in proper english. Some of us find it-gasp!-easier to read a post written properly, And some of us-gasp!-take a well written post more seriously than one written in god-knows-what.
<strong>
And the reverse is true. There are a number of Carbon features that Cocoa cannot access. So the two APIs are roughly even.
</strong>
<hr></blockquote>
Oh reaaaally? Like which ones genius boy!? Back up you claims, or nobody will be able to *you* seriously even if you programmed Cranberry, a decent app (albeit with shitty non-Aqua toolbar icons).
[quote]
<strong>
But you *can* do all of these things in Carbon. They may require extra work, but it will achieve the same goal in the end.
</strong>
<hr></blockquote>
Yes, yes, yes...selective quoting will get you nowhere. I mentioned that all of this can be done but with 'extra work'...and most developers aren't ready to put this extra work in. Except a handful of developers...including you.
I'm sad and hurt that you felt like the target of my rantings. Haven't you heard that there's 'exceptions to [most] rules?' You, Andrew Welch and the boys at Panic are this exception.
[quote]
<strong>
*I* am not a "lazy wanker." I have spent hours trying to make my *Carbon* app (see above) look and behave just like a Cocoa app. Heck, I've even spent money on it! And I'm giving away my app!
</strong>
<hr></blockquote>
Good for you...I hope there are more good carbon developers like you out there. So far there aren't many. You're a respectable developer...but alas, you can't say your app behaves like a cocoa app. You'd be wrong.
[quote]
<strong>
And you would be wrong.
PS-If you want anyone to take you seriously, you need to learn how to write in proper english. Some of us find it-gasp!-easier to read a post written properly, And some of us-gasp!-take a well written post more seriously than one written in god-knows-what.</strong><hr></blockquote>
Nah, I wouldn't be wrong...99.9% of the developers won't put the required effort into a carbon app to make them on par with cocoa apps. Therefore carbon sucks.
Obviously you did take my poorly written post seriously if you took the time to dissect it bit by bit. Thank you for proving yourself wrong.
That is all...buhbye now.
<strong>
Oh reaaaally? Like which ones genius boy!? Back up you claims, or nobody will be able to *you* seriously even if you programmed Cranberry, a decent app (albeit with shitty non-Aqua toolbar icons).
</strong><hr></blockquote>
Whoa, I take my comment back...I actually downloaded your app and tried it out.
1st mistake...REALBasic. LOL!
Here's a list of things missing in your app that I've discovered in the first 30 seconds of testing:
No scrollwheel support.
A half-assed sheet implementation (sometimes save invokes a sheet...sometimes it doesn't.)
No customizable toolbar (or is that a cocoa-only feature...the Finder has it but is it a hack?)
No services support.
Here's a list of missing features that aren't your fault because they're cocoa-only features:
Drawers.
And here are non carbon-vs-cocoa-related issues:
Here's a bug I saw in the first 5 seconds of scrolling some Marathon scripts:
Text occasionally scrolls out of the text field. Screenshot to come.
Things I'm not too impressed with:
Your sucktacular application icon and the toolbar icons.
Sorry, bub, your app doesn't pass the test...and I haven't even tested it fully. I'd probably find a lot more problems and carbonish pet peeves if I took any more time.
[ 03-24-2002: Message edited by: kim kap sol ]</p>
<strong>
Whoa, I take my comment back...I actually downloaded your app and tried it out.
1st mistake...REALBasic. LOL!
</strong><hr></blockquote>
And would you please explain why REALbasic is a mistake?
[quote]Originally posted by kim kap sol:
<strong>
Here's a list of things missing in your app that I've discovered in the first 30 seconds of testing:
No scrollwheel support.
</strong><hr></blockquote>
I don't have a scrollwheel mouse. So I haven't had a chance to implement it. And plase remember that the application is in BETA testing: some things may not be there or work as expected.
[quote]Originally posted by kim kap sol:
<strong>
A half-assed sheet implementation (sometimes save invokes a sheet...sometimes it doesn't.)
</strong><hr></blockquote>
Could you explain further?
[quote]Originally posted by kim kap sol:
<strong>
No customizable toolbar (or is that a cocoa-only feature...the Finder has it but is it a hack?)
</strong><hr></blockquote>
It is a hack in the finder, and in my app, there is no need for customization (what you see is what you get).
[quote]Originally posted by kim kap sol:
<strong>
No services support.
</strong><hr></blockquote>
See above - It's a BETA!
[quote]Originally posted by kim kap sol:
<strong>
Here's a list of missing features that aren't your fault because they're cocoa-only features:
Drawers.
</strong><hr></blockquote>
A short list that is irrelevant because I have no need for drawers. And many people dislike them, myself included.
[quote]Originally posted by kim kap sol:
<strong>
And here are non carbon-vs-cocoa-related issues:
Here's a bug I saw in the first 5 seconds of scrolling some Marathon scripts:
Text occasionally scrolls out of the text field. Screenshot to come.
</strong><hr></blockquote>
Don't bother. Its a known bug.
[quote]Originally posted by kim kap sol:
<strong>
Things I'm not too impressed with:
Your sucktacular application icon and the toolbar icons.
</strong><hr></blockquote>
That would be an OPINION, and therefore carries no weight.
[quote]Originally posted by kim kap sol:
<strong>
Sorry, bub, your app doesn't pass the test...and I haven't even tested it fully. I'd probably find a lot more problems and carbonish pet peeves if I took any more time.
</strong><hr></blockquote>
So, are you saying that every Cocoa app is perfect because it is Cocoa, and that Carbon is bad because it is Carbon? I'd bet that I could find a bunch of problems with Cocoa apps to criticize.
[edit: spelling]
[ 03-24-2002: Message edited by: graphiteman ]</p>
<strong>
I don't have a scrollwheel mouse. So I haven't had a chance to implement it. And plase remember that the application is in BETA testing: some things may not be there or work as expected.
</strong><hr></blockquote>
Typical answer...
[quote]
<strong>
Could you explain further?
</strong><hr></blockquote>
Quitting the app through the menu or through cmd-q will make the save sheet drop down if you have some unsaved changes. Using 'Save' or 'Save As' from the menu will not make a save sheet drop but instead make the save dialog box pop up.
[quote]
<strong>
It is a hack in the finder, and in my app, there is no need for customization (what you see is what you get).
</strong><hr></blockquote>
Another typical answer to defend carbon..."I don't need to customize my toolbar, so you don't either."
So here we have the first reason why carbon is crap...uncustomizable toolbar. While I don't much care if a toolbar is customizable or not...I do care about consistency. Carbon and cocoa apps do not feel or act the same way (they might to the untrained eye I guess).
[quote]
<strong>
See above - It's a BETA!
</strong><hr></blockquote>
Yes, yes, yes, I see what you're doing here. Because it's beta you're exempted from any of the comments I make about your application.
Don't announce your program as a model carbon app if it's not...I don't care if it's beta or not.
[quote]
<strong>
A short list that is irrelevant because I have no need for drawers. And many people dislike them, myself included.
</strong><hr></blockquote>
I agree, this one is a gray area...if not implemented properly, drawers can be a pain more than anything else. Although I can think of some ideas of what you could have done with drawers if your app was cocoa. If you want my ideas, say so...I'll send you an email and some GUI mockups (although I bet you don't want my ideas now that I've ridiculed your app. It's up to you if you want feedback and ideas.)
[quote]
<strong>
That would be an OPINION, and therefore carries no weight.
</strong><hr></blockquote>
You're right...it's an opinion and it carries no weight. But I do enjoy consistency with the Aqua GUI and icons that don't follow the guidelines stick out like a sore thumb.
[quote]
<strong>
So, are you saying that every Cocoa app is perfect because it is Cocoa, and that Carbon is bad because it is Carbon? I'd bet that I could find a bunch of problems with Cocoa apps to criticize.
</strong><hr></blockquote>
Nope...not saying that at all. Just saying that cocoa is better for the developer and the end-user.
Better for the developer since you inherit behaviors/features for free such as a scrollwheel support, services, customizable toolbars, sheets etc...
Better for the end-user because consistency is where it's at. Having scrollwheel support in on app and lack of scrollwheel support in another is no good. Having customizable toolbars in one app and lack of customizable toolbars in another is no good. Having services in one app...well you get the picture right?
You say that you haven't put in scrollwheel support because you don't have a scrollwheel mouse. Fine. But if you were programming in cocoa, you wouldn't need a scrollwheel mouse to test out scrollwheel support because the scrollwheel support would be there already.
Anyways...my advice to you is: Don't announce your program as a model carbon app if it isn't. I understand it's still in beta but you have to realize that you asked for it by telling me that your app is a great carbon app that couldn't be differentiated from a cocoa app.
[ 03-24-2002: Message edited by: kim kap sol ]</p>
please post here more <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
<strong>kim kap sol,
please post here more <img src="graemlins/lol.gif" border="0" alt="[Laughing]" /> </strong><hr></blockquote>
Why?
<strong>
Anyways...my advice to you is: Don't announce your program as a model carbon app if it isn't. I understand it's still in beta but you have to realize that you asked for it by telling me that your app is a great carbon app that couldn't be differentiated from a cocoa app.</strong><hr></blockquote>
OK, well let's end this discussion (It was fun, wasn't it?). I would like to hear your suggestions; it will make Cranberry a better Mac OS X citizen.
A few notes:
The way that I am implementing toolbars is with a 3rd party module that actually draws everything like a Cocoa app does. It does not access the NSToolbar class (It's not accessable to Carbon apps, IIRC). The customize sheet would be extremely difficult to do as the sheet must come out of the toolbar and not the title bar, and I don't believe that to be possible in Carbon.
I thought REALbasic had Scrollwheel support, I'll double check that. And if it doesn't, I know of another way to do that. To be honest, you are the first person to even make me think about it.
Save sheets shouldn't be too hard to do.
I apprecate your poiting these things out, as I want my app to be a first class citizen in Mac OS X.
PS-I would still like to hear how RB is a mistake
<strong>PS-I would still like to hear how RB is a mistake
Of course, that doesn't mean *all* RealBasic apps are inherently bad. Though, there have been SO MANY bad apps, it's hard to shake the reputation.
<strong>Most people have a hatred for RB apps because most of them are crap. Just look at the comments for some of the uglier RB apps on VersionTracker! Whoo-boy! RB has a history of major, annoying GUI bugs with OSX including the rainbow-colored text (which I think was fixed) and the mis-aligned background "pinstripes" behind widgets like checkboxes, text fields, and the like. Plus, many RB apps seem extraordinarily l-a-r-g-e and s-l-o-w.
Of course, that doesn't mean *all* RealBasic apps are inherently bad. Though, there have been SO MANY bad apps, it's hard to shake the reputation.</strong><hr></blockquote>
The Rainbow colored text issue was fixed 6 months ago, and the misaligned pin stripes issue has been fixed in the 4.5 alphas. The reason that took so long is that it required a complete rewrite of how the interface was handled to support a parent-child relationship between, say, a button and a tab panel.
As far as the slowness issue, REAL Software is writing a new compiler (which is now available in the form of RBScript) that will be included into REALbasic as the main compiler in the near future (probably 5.0).
I just wanted to clear up these myths.
I just saw this on VersionTracker. This might hopefully help you implement the new carbon events without much pain.
<a href="http://www.versiontracker.com/moreinfo.fcgi?id=12933&db=macosx"; target="_blank">Carbon Events RB Plugin</a>
I don't think the Finder problem is related to any kernel mutexes.
- Unix file systems store each directory in a regular file, containing the names of the files in that directory and their inodes. If you want to read file specific information, you have to iterate over all these files (inodes). The OSX Finder provides such information (modification date, size etc.), thus a lot of inodes have to be read if you do a directory listing. However, this is of course not done with only one low-level system call but with at least one for each file (I don't know OSX's vfs, but it will ultimately come down to some sort of lookup/get call). So, if you have to go through a lot of files, you can easily stop at every point and switch to another thread, leaving the Finder fully responsive.
- Even if you're right with your funnel theory, connecting to an iDisk should not block local disk operations or even general event handling in the Finder since I don't think that reading a local directory or selecting a folder does actually perform network system calls, do you?
- I also don't think that connecting to an iDisk is only one BLOCKING sys call, and iDisk navigation even less. Therefore you should be able to connect and navigate several iDisks in parallel without having to wait for each operation to fully complete. (Webdav uses tcp, which means that all connect/send/receive operations can be done asynchronously.)
Conclusion: The Finder does use multiple threads for file copying etc. but doesn't do so for event handling and navigation(dir-listing). I call this a very bad design. IMHO, locks may indeed be the problem if you want to do several dn lookups at the same time or somethink similar, but not if you want to work with a big/remote directory and always have a completely unresponsive Finder.
123
[ 03-27-2002: Message edited by: 123 ]</p>
<strong>Most people have a hatred for RB apps because most of them are crap. </strong><hr></blockquote>Monica is great; although it'd be greater if it re-connected when a download is interrupted as well as the OS 9 version did (I have a feeling it's Apple's fault, though)
I clearly said that I don't think all RealBasic programs are bad. I use several StimpSoft (RIP) apps regularly and they're all written in RB. I simply wanted to state the simple truth that RB has a bad reputation because of the shabby apps out there that were written by amateur programmers. At least 2/3 of the RB apps I download go straight to the trash because they're just ugly, disorganized, and slow. This isn't entirely RB's fault but much of the programmers.
Play it cool, guys. :cool:
[ 03-27-2002: Message edited by: starfleetX ]</p>
<strong>
As far as the slowness issue, REAL Software is writing a new compiler (which is now available in the form of RBScript) that will be included into REALbasic as the main compiler in the near future (probably 5.0).
</strong><hr></blockquote>
They also said that this would be incorporated into version 4.x, but as we all know, it wasn't.
-------THE FINDER------
As has been previously stated:
The Finder is not a Cabon Port of a legacy finder to OS 10.
I've opened mine up a few times with different tools, and I think if you open it using resorcerer for X it says "Fake Finder" right there.
I think of it as what pins the dock down in place at it's starting point, and all apps float in to the dock from there. Apple could have called it anything. I think they used the finder to make you more comfortable. Sometimes I thnk it lags because some of the XML utilization in the dock could be optimized better, but I'm not sure realy because I'm not all that familiar with XML yet so I'm essentaily talkin' out of my ass.