Ten Things I Dig About Xcode
by James Duncan Davidson, author of the upcoming Running Mac OS X Panther10/24/2003
Following in the footsteps of the Ten Things I Dig About Panther article that was published on October 10, and to celebrate the public release of Mac OS X today, I've decided to focus in on the eleventh item from that list, the revamped IDE, called Xcode. There's a lot to like about Xcode, and the rest of the toolset now known as the Xcode Tools.
As with the last article about Panther, this is by no means an exhaustive feature-based review. To be honest, it's going to take a bit of time to pull together a really good review of the new Xcode IDE and to explore all of its capabilities. But, in the short amount of time that I've played with Xcode so far, these are the things that I've found myself really digging about it.
1. New User Interface: The first and most obvious thing you'll notice about the new Xcode IDE is that the Project Builder interface of old has been totally replaced with a new and much more polished UI. The old Project Builder interface was functional--good enough for day-to-day work, but evidently was not something that Apple was happy with. So they brought in their UI experts--the same ones that worked on the new Finder and iTunes--and rethought how the IDE should go together. The result is something that just plain feels a lot more polished and honed.
|
2. Smart Lists: The new UI is more than just window dressing. The Xcode team is out to make sure that you can drill down to just the code that you want to focus on. Think about how Smart Playlists work in iTunes. Now, apply that to an IDE and you have an idea of how these lists work. For example, if you click on a target in Xcode, you'll just see the files related to that target. It's a small thing conceptually, but in large projects with lots of targets, it's quite handy to drill down to just the code that you are interested in at the moment.
|
3. Symbol Browsing: So far, my favorite mode of working with code in Xcode isn't a bullet-point item on Apple's web site, but it should be. It's the Project Symbols view--instead of navigating your project file by file, it allows you to take a look across all the symbols in your project--the classes, methods, functions, and variables that make up your application. In the short time that I've been playing with Xcode, I've used this feature more than any other to navigate through the source code in my projects.
|
4. Fast Search: Just like iTunes, the Xcode IDE sports a quick-find box in the toolbar that allows you to drill through the items in the main list. Combined with the smart lists, this will let you find anything you are looking for in a snap.
|
|
Second, the errors and warnings are flagged with icons in the gutter of the text editor. This indicates quickly what line an error is on while letting you just work with the code, without a lot of clutter in the way. Very elegant and nice.
|
6. Three Pane/One Window Use: Even though by default Xcode opens source code in separate editor window, you can activate the one feature I really liked about Project Builder: The ability to have a single window for navigating and editing your code. To enable this, simply hit the three-pane icon in the toolbar.
|
7. Documentation Viewer: Lucky seven and one of the best. Again, this isn't a feature that's been pushed on the Apple web site before the release of Panther, but it's one that I think is the biggest help of all--the ability to quickly and easily go through the Apple developer documentation. The documentation viewer sports a quick-find box in its toolbar (like Finder and iTunes and Mail and... you get the point) and it lets you blaze through the documentation in a flash. Before this feature I was a regular user of both Cocoa Browser and AppKiDo. Now, I find myself using the built-in documentation viewer all the time and prefer it over either of those two tools that I used to rely on so much. Both Cocoa Browser and AppKiDo have features that aren't in the Xcode documentation viewer, but the single ability to quick search through the documentation makes those features less critical to have.
|
8. Code Completion: Finally this useful, and long overdue, feature comes to the Apple developer tool suite. I've always been a fan of being able to save keystrokes, and the code-completion features in Xcode promise to help shave off a bit of time--as well as repeated trips to documentation to remember how to spell a particular method. There are a few key sequences you can use to activate code completion: Hit Control-. (period); Option-Escape; or F5 (or fn-F5 if you are on a PowerBook). These keystrokes will pop up a window from which you can pick the appropriate item. You can also turn on code completion full-time in the Navigation section of the Xcode Preferences. I'm sure that this will cause a slight performance hit on slower machines, but it seems to perform well on my PowerBook.
|
9. Predictive Compilation: I'm a big fan of letting the machine do as much work as possible in the background while I'm thinking about other things. Instead of making me wait on a compile, predictive compilation promises to speed up the process quite a bit. Instead of waiting for you to hit the build button, Xcode will go ahead and compile changes in the background--and then commit them to disk when you hit the build button. I haven't had the chance to exercise this feature with a large project, but so far, it seems to work as advertised.
10. Revamped /Developer/Applications Directory Organization: The /Developer/Applications directory was getting a bit crowded. In Jaguar with the developer tools, it was always a crapshoot whether you'd have to scroll in column view to find the Project Builder icon. Apple must have realized that 90 percent of the time, when you go to that directory, you want to launch Xcode, so they cleaned it up and moved the various accessory tools to their own subdirectories. Now just Xcode and Interface Builder applications appear in this directory.
|
Just like with the Panther article, it's too hard to limit myself to just ten items. So, here's one more...
11. Rendezvous-Enabled Distributed Builds: This one is probably the excuse that I'll use to go ahead and buy that dual G5 machine I've been lusting over. At MacHack this year (which was the weekend before WWDC), there were a few of us gathered around talking about our hacks. One guy had the idea of doing distributed compilation with Rendezvous. He didn't finish his hack, but just a few days later we saw the same idea demonstrated at WWDC in a demo of the axiom that great ideas show up in more than one place at once. It's nice to see Rendezvous being used for more than just chatting and music sharing (much as I use those two features all of the time). I foresee lots of interesting things in the future when it comes to Rendezvous and Xcode.
|
Mac OS X 10.3, widely known as Panther, is available from the Apple Store. Apple includes the developer tools with the operating system, so you can start working with Xcode right away. |
There are so many other cool features that I could talk about here. Zero Link and Fix and Continue come to mind. But so far, these are the ten, 'er eleven, things that I've really been enjoying about using Xcode. It definitely represents a major shift in Apple's IDE and I think it will take people a little while to get used to this new tool. It's also different enough than Project Builder and other IDEs that it's going to take a few months to really start getting the hang of how to best utilize it, but there's some serious potential here and I'm really happy to see Apple investing the same kind of attention into the IDE that it put into iTunes, iChat, and the rest of the applications that ship with Mac OS X.
Of course, as great as the new Xcode is--and how far things have progressed since the last release of the developer tools--there is always more that could be done. There are many things that I would like to see in future versions. Here are a few of them:
The ability to build a distribution build directly into a package without having to use Package Maker externally. It should just be a one-click build command from within the IDE to make a complete, ready-to-ship binary.
The ability to define subprojects or declare dependencies on other projects. Sure, you can structure targets together for quite a bit of flexibility, but there are several bits and pieces of code that I reuse among many of my projects and I'd like to just declare a dependency on that project instead of either creating a target separately in each project or importing the code.
The ability to integrate unit testing tools into Xcode. Agile programming is all the rage these days--and for good reason. Test-first development has changed the way I create code. Currently, the existing tools have had a limited amount of integration with Project Builder. What I'd like to see is the ability to design unit tests alongside the code, and have the test errors show up in the "Errors and Warnings" list as well as in the editor gutters. There are a few ways this could be done, but Apple is probably going to have to expose a bit of functionality for the tools to plug in nicely.
However, I'm willing to wait a little bit for these features to hopefully come to the toolset. This release of Xcode is a welcome improvement and a big thumbs up goes out to the Apple Xcode team for all the hard work they've put into it.
James Duncan Davidson is a freelance author, software developer, and consultant focusing on Mac OS X, Java, XML, and open source technologies. He currently resides in San Francisco, California.
Return to the Mac DevCenter
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 38 of 38.
-
Code completion in Java
2003-10-24 13:26:54 bashyal [Reply | View]
-
Code completion in Java
2003-10-25 06:50:10 anonymous2 [Reply | View]
The release notes (and my experience) state that code completion does not work in Java. My guess, and hope, is that it will in a future version.
I'm also finding that errors and warnings for my Java project aren't being displayed in either the "errors and warning" group or the gutter, as described in this article. For Obj-C, it's working, but no dice for Java.
But I can't even run a Java program that opens a window (Frame). Perhaps these problems are because I did an upgrade install versus an archive-and-install. I'll probably reinstall and see how that goes.
This is from just one day of playing with Panther, but I'd like to know if anybody else experienced these sorts of problems. -
Code completion in Java
2003-10-28 10:20:39 anonymous2 [Reply | View]
I've been using XCode too for Java. Or rather I haven't. Sure would be nice if code completion worked (I know the Java keywords and don't need to be reminded) and errors were shown anywhere at all. -
Code completion in Java
2003-11-22 12:07:02 anonymous2 [Reply | View]
Codewarrior 9 has made significant improvements. I'm glad Apple finally updted from version 8 to 9.0
I can hardly wait for 10!
so is that what they call 9? xCode? i think the original name (CodeWarrior) sounded much better.
AppleSoft.com
-
Uhh...
2003-10-25 09:35:45 anonymous2 [Reply | View]
Great review, except you forgot to mention that because of many bugs Xcode is almost unusable in many aspects. It is of course understandable, as it's in early iterations and can be compared to early ProjectBuilder in Mac OS X 10.0, but still it is riddled with various bugs, small and big. I am sure Apple will be improving the situation, though, but Xcode in it's current shape cannot be recommended as a development environment as-is, IMHO. -
Uhh...
2003-10-26 16:40:53 anonymous2 [Reply | View]
I agree completely. I hadn't really used the new versions of XCode/IB until I got my copy of Panter. I had no idea what I was in for with regards to stability. And because I did an archive and install when installing Panther the frameworks for the older versions aren't there so I can't run PB. I've been reluctant to copy things over to try to make the old versions work, but I'm afraid I may not have a choice.
Is anyone else finding IB especially to be very crash prone? I find a lot of errors with "inconsistencies" which then lead to complete meltdowns. Often I can't even get the nib file open to fix it.
Anyway yes this is an early iteration, but it's still a released product and I hope for apple's sake that my experience isn't the norm. -
Uhh...
2003-11-18 14:27:06 anonymous2 [Reply | View]
Wonder if it's just my configuration, but I also found XCode (1.0.1 running on Panther 10.3.1) unstable to the point of being unusable! It also seems to lack the flexibility of ProjectBuilder, e.g. reordering or moving files between build phases.
One of the most annoying things is files I add to my project tend to disappear from it when I close and reopen it.
Can only hope Apple quickly releases a decent upgrade. Otherwise, I wonder what are my options for reinstalling ProjectBuilder on top of the current Dev Tools... -
Uhh...
2003-11-19 12:30:30 anonymous2 [Reply | View]
Got around my above problems. Looks like this happens when using sub-projects... Maybe something wrong with the project I was including. Anyway it caused the including project to behave very strangely, basically ignoring any attempt at changing anything. Reordering or moving files now works.
Think you have to be careful and save copies frequently in case your project becomes corrupted for some reason...
-
Uhh...
2003-10-28 13:45:40 leeharveyosmond [Reply | View]
Ditto.
It is easy to be dismissive of a new IDE/build system; after all, it's different from what you're used to. The first IDE I was prepared to tolerate was the NEXTSTEP 3.3 ProjectBuilder. In time -- and it was a long time, but I did get there -- I came to really adore the OPENSTEP 4.2 ProjectBuilder. And I was prepared to believe that I'd like "the new Project Builder", one day, if and when it was finished.
But Xcode plain sucks. The consistency of keystrokes is just missing. Whatever you were used to in ProjectBuilder or whatever will have changed, and will change again. And again. [So this can't be some sort of CodeWorrier emulation thing.] Am I supposed to be clicking here? Or double-clicking? Or triple-clicking? Or modifier clicking? Time to stop guessing, and go to the menu.
I'd like to say that if searching the documentation has improved that's good, but that'll I'll believe it when I see it. But I can't honestly say that; I can say that I'll let you know what I think, if I ever find it.
#include <appkit/DigitalLibrarian/nostalgia.h>
ls ~/bin/darwin/DocumentationSearcherScripts/*.sh
In the meantime, I've imported a very simple PBX Project Builder project, and the Xcode build tool knows what the install location is, but Xcode won't show me, so I can't change it. And not all of us have a bunch of 21" displays in a multiheaded configuration attached to something so factory-fresh and speedy that you can smell the loose plastic monomers, and Xcode does indeed bite here too.
So what I'd love to do is create something lean and minimal and cussed, much like something that could grow into the NX3.3 ProjectBuilder; it'd be a pretty front end to 'gnumake' and 'grep', and I could customise the makefiles to my heart's content 'cause I'd know how they work and I trust gnumake; and I could use the text editor or editors of my choice; and I would have to do without zero-point links or whatever they're called, and filtered prettified compilation error panes, and tight integration with InterfaceBuilder; and if I ever implement this daydream, I can get back to thinking about code instead of thinking about Xcode being in the way when I need to do something.
Serves me right for those jokes about comprehensive hermeneutics being a useful limbering-up exercise in preparation for reading the Win32 API references I suppose.
Grrrrr.
-
Subprojects and Unit Tests
2003-10-25 10:02:17 iapole [Reply | View]
Nice article; good quick overview.
As for your wants, I should note that there was something in the Xcode release notes about subprojects. I believe that you can now add a project to another project and have your targets in the enclosing project depend on targets in the subproject.
Also, there are unit testing frameworks available which do just this. I don't know much about them, but OCUnit and ObjCUnit (I think) are both just exactly like that. As to whether they work in Xcode yet or not, I dunno. -
Subprojects and Unit Tests
2003-10-25 18:14:44 anonymous2 [Reply | View]
I just came across this quote on apple's "Xcode: A First Look Page":
"This [Flagged compile errors] increases the utility of the gutter, which previously was used only for breakpoints. In the future, we hope to see even more information about code represented here. One example would be to put pass/fail annotations from test units into the edit view."
Afterall, we can dream, can't we -
Subprojects and Unit Tests
2003-10-25 18:17:08 anonymous2 [Reply | View]
I'm the anonymous who just wrote this above. I just discovered that apple's article was written by James Duncan Davidson, the same person who wrote this article.
Oh well, it was nice to think that it was coming for a while.
Thanks for your great articles (both of them)
-
Am I the only person who's baffled by the new Xcode?
2003-10-26 09:43:43 anonymous2 [Reply | View]
Hi,
I'm an avid, albeit hobbyist, programmer -- relatively new to OSX (coming from linux) and have written code for several platforms (embedded motorola chips, win32, java, BeOS). So, for what it's worth, while I'm no professional, I have quite a bit of experience with different IDEs as well as the good old configure/automake/make triumvirate. I've made a lot of IDE/build environment transitions, and I always manage to blindly grope my way through.
Coming to OS X, the best thing, I thought, was how straightforward Project Builder was -- it only took me a couple weeks to grok it; hell, most of it I figured out just porting over my old code from linux. I learned it by using it. I also bought some O'Reilly books, of course, to familiarize myself with Cocoa and Darwin.
Anyway, I've been hammering on Xcode for the last couple days now, and frankly, I feel like a babe in the woods. It's not like I'm averse to change -- it's just that PB was *simple* enough that it was easy to do a number of diverse things... dare I say: PB seemed lightweight. Xcode seems more like... emacs (if PB could be compared to VI). I'm lost! It's like having your dishwasher be replaced with an industrial autoclave.
Thank god my old PB projects build still, but I'm having a hell of a time doing the simplest things like making a new dynamic library and having it "see" internal project dependancies correctly. I'm working on a system that's heavily dependant on plugins, and while my *old* plugin targets still work, I can't duplicate them -- the vanilla "Library" option is gone. The old ones seem to have been given a legacy "grace" target of some sort. And the new library options won't build.
Well, I'm sure that given a couple weeks I'll figure this hoo ha out. But it's a shame that it's going to have to be like going through high-school all over again. Confusion, akwardness, shame, and failure. A big waste of time.
Personally, I'm ready to shell out whatever it costs for anything O'Reilly publishes that purports to teach me Xcode. I'm excited about the improvements Xcode delivers... particularly in regards to live searches and better SCM. I just wish the Xcode docs had a "what's new and how to grok it" section.
Sincerely,
A baffled programmer. -
Am I the only person who's baffled by the new Xcode?
2003-12-26 11:23:52 anonymous2 [Reply | View]
"Xcode seems more like... emacs (if PB could be compared to VI). I'm lost! It's like having your dishwasher be replaced with an industrial autoclave."
On the contrary: PB is like pico: it's more than a basic editor, but you can grok it pretty quickly and it's often self-explanatory. Now BBEdit, there's your vi...
-
Errors and Warnings
2003-10-26 11:04:51 anonymous2 [Reply | View]
I too can't seem to get the "errors and warnings" smart list to work.
I'm compiling a Java project, and any errors show up in the "detailed build results" window, but not the "errors and warnings" list, which is greyed out 90% of the time and filled with bogus errors the other 10%.
Anyone been able to get this to work? -
Errors and Warnings
2003-10-26 21:11:49 jimothy [Reply | View]
Submit a bug to http://developer.apple.com/bugreporter/ , as I just did. So far, I've only had the "errors and warning" group greyed out, so you'll be able to provide them with a different test case. Plus, it helps to have additional bug cases so they know this is affecting a number of users.
-
not really...
2003-10-27 06:33:31 saneh [Reply | View]
XCode has what looks like a lot of cool features, but the UI is so buggy, it's extremely painfull to use. I'm keeping a jaguar box to do developement until usable version comes out.
Amongst unbelievable UI bugs:
- when you edit multiple files, you ask to compile, you get the window asking to save the files, but hitting enter does not "click the default button" of the dialog. Instead, you have to click manually with the mouse.
- when you ask for a single window to edit file, the tool insist on opening a new window every time you ask for a new file from the keyboard.
it goes on and on... This tool *IS* unusable!!! unless you are willing to put up with at lot of frustration.
stephane
-
XCode java and Extensions
2003-10-27 19:48:21 anonymous2 [Reply | View]
How does XCode handle Java Extensions.
For example, if I drop in a .jar file into
Applications/Java/Extensions/HttpUnit.jar
will XCode pick it up, and will I be able to
import com.meterware.httpunit.*;
We need a java documentation update for XCode.
-
xCode for ObjC/Cocoa App
2003-10-28 22:53:16 anonymous2 [Reply | View]
I actually liked Project Builder, but made the switch to xCode to keep up with the Jone's. The transition has gone smoothly. I am not seeing all the crashes that some have reported.
My application is a straight forward Cocoa ObjC development. My Project Builder project imported nicely into xCode keeping all the build styles. The debugger doesn't seem quite as reliable.
I turned off the auto code completion as it was slow and just wasn't intuitive enough.
One thing I liked about Project builder was containing everything to one window. XCode seems to allow editing in one window, but that's about it.
I don't really see Xcode as an improvement, just a change. So for now I will stick with xCode.
I considered using Java for the development, but the performance was so substandard to the native Obj/Cocoa API's.
-
This is a general problem with the Mac GUI
2003-10-29 08:55:42 anonymous2 [Reply | View]
"when you edit multiple files, you ask to compile, you get the window asking to save the files, but hitting enter does not "click the default button" of the dialog. Instead, you have to click manually with the mouse."
I hate to say anything nce about Windows, but in Windows keyboard navigation is a first class citizen, not an afterthought. Regardless of the API you use, what apple calls "full keyboard navigation" is enabled... and it goes far beyond what Apple provides.
I use a Mac at home and Windows at work, and every morning and every evening I go through a frustrating readjustmant. On the Windows side it's the usual "you never know what the h*ll Windows is doing" problems. On the mac it's going back to the "one hand on the keyboard one hand on the mouse" navigation... not only does Apple have lousy keyboard navigation, but if you're mousing around you have to keep your fingers ready for option-click and command-click. -
This is a general problem with the Mac GUI
2003-12-04 00:41:34 anonymous2 [Reply | View]
Exactly!!!
I hate mac. Mac sucks sucks sucks in keyboard navigation.
Windows is the mother of keyboard navigation.
I wish mac could learn from windows.
I especially like Alt+<underlined menu items>, which
is sort of universally works everywhere even if you
happen to forget the shortcut keys. -
This is a general problem with the Mac GUI
2003-12-30 07:31:46 anonymous2 [Reply | View]
You didn't mention that they have one-button mouse :-) -
This is a general problem with the Mac GUI
2004-01-01 23:35:46 anonymous2 [Reply | View]
Sure, but YOU didn't mention that two button mice work just as well on macs as on any other computer. It's just that Apple doesn't make them. -
This is a general problem with the Mac GUI
2004-01-18 22:26:48 anonymous2 [Reply | View]
Actually any Mouse with any number of bottons will work well in OS X, I use an intelliMouse Explorer and OS X allows programability for all those extra buttons...
OS X's Aqua GUI has no general problems its only that your point of view has you looking at it differently. Microsoft made headway with XP's Luna GUI, and supposedly "longhorn" will be even better, but as far as system stability and ease of use Mac OS X is still a decade ahead of Microsoft, and will be for the forseeable future... -
This is a general problem with the Mac GUI
2003-12-17 13:59:43 anonymous2 [Reply | View]
What are you talking about?
I can't recreate the problem you describe when using 1.0.1, are you using an early version or something?
If "enter" doesn't click the default button, the space bar always does...
besides, what rational reason would you have for not using "always save" when compiling? Use an SCM tool and have XCode save files for you.
-
XCode
2003-10-29 13:31:33 anonymous2 [Reply | View]
I like XCode and had no problems moving from Project Builder whatsoever with my Giant Java Project. That's the first time moving from one IDE to another, or even moving within the same IDE from version to version, hasn't required me to rewrite at least one line of code before a successful first compile. I eagerly await the "native" Java target for the IDE, so that I can play with the runtime relinking too! Congratulations, Apple, and thanks!
-
XCode NRFPT
2003-10-30 09:35:21 anonymous2 [Reply | View]
I have been using XCode since the original release, and I'm afraid that it is mostly smoke and not much fire. Most of the much-promoted features (distributed compiles, zero-link, fix-and-continue) either don't work or don't deliver on their promises, and the UI is a mess compared to PB, which wasn't any prize.
IMHO, Apple should have simply added the speed features to PB and _called_ it XCode -- the UI didn't need to be made both more complicated and less useful. The manhours saved could have been used on making the speed features actually work correctly.
Simple, basic example of the klutzy new world of XCode:
Say you notice that you have several files in the source-code list that are "dirty". You command-select them all, and attempt to "Save", because XCode has an annoying habit of crashing at bizarre moments.
Oops, Save is not available -- the only way to select Save is one-file-at-a-time, and the file editor itself has to be the first responder, not the file list. Really dopey.
So you go to Save All -- and instead of Saving All, you get a window asking you if you REALLY WANTED TO SAVE.
How stupid is this?
A giant step backwards in fundamental usability.
We won't even talk about how the Find functionality has been gutted.
And if anyone can tell me an easy way to embed a framework in an application while not including the headers, I'm all ears. I would use a static library, but of course static libraries don't import objective-c categories correctly -- an amazing bug that should have been targeted a long time ago instead of wasting Apple man-hours on replacing the PB UI with an inferior one.
And while I'm whining, what genius decided that "Project>AddFiles..." would disallow adding a file from inside the project folder? How brain-dead is that? Someone actually had to DECIDE to do this. Actual man-hours were spent implementing this silliness!
I find it hard to believe that Apple's own development team is using XCode -- every time I try to do something new, I spend hours fighting the development environment.
-
XCode NRFPT
2003-12-09 11:27:09 anonymous2 [Reply | View]
And while I'm whining, what genius decided that "Project>AddFiles..." would disallow adding a file from inside the project folder? How brain-dead is that? Someone actually had to DECIDE to do this. Actual man-hours were spent implementing this silliness!
I find it hard to believe that Apple's own development team is using XCode -- every time I try to do something new, I spend hours fighting the development environment.
-
J2EE
2003-10-30 10:23:25 altjeringa [Reply | View]
Where did J2EE go? Did I mess something up on install or did Apple drop J2EE Xcode support when they went GM. It was there in the Developer releases. Oh well, looks like JBuilder is finally releaseing for OS X again.
-
Adding Additional Libraries
2003-11-05 03:48:00 anonymous2 [Reply | View]
My question does Xcode offer the ability to plug-in libraries or API's, for example, ColdFusion or ActionScript?
-
it's a shame..
2003-11-26 17:27:39 anonymous2 [Reply | View]
from the point of view a java programmer, it's interesting to note that project builder's achilles heel was its lack of code completion.
i was going to say that i was a fool to think that code completion would work this time (java). but now that i think of it, i wasn't a fool; i was simply lied to.
not only was the product renamed, hyped, but it advertised code completion!
having read the discussion threads to this article, i now realize that of all features, code completion is not even addressed for java programming (and care must have been taken to hide this information (side note: i'd rather be told it not work than be lied to)).
what exactly does this say about this "xcode" product? my conclusion is that java developers should not hang their hopes (and waste their time) on ide's with the apple brand, unless they submit to writing proprietary code.
well, at least there's a java runtime on this os.
i should have listened to uncle bob when he said: get either of these two ide's: intellij idea or eclipse
-
it's a shame...that you are a moron.
2003-12-06 08:54:18 anonymous2 [Reply | View]
C, C++, and Objective C are not proprietary languages. Java's APIs are no more free or open than Win32 or Cocoa. GnuStep is a free implementation of Cocoa/NextStep; WINE is a free implementation of Win32. Have the GNU folks gotten around to building a free implementation of Swing yet? JDBC? JNDI?
Enough with the self-righteous, anti-proprietary posturing. You act as if you're interested in libré, but all you really want is free beer, perhaps cross platform free beer.
-
it's a shame...that you are a moron.
2004-01-02 16:28:01 anonymous2 [Reply | View]
I agree no one would right a quality OS X application using Java & Swing. They lack the performance or feel of a native app OS X Cocoa app. Take one look at the Java API source and you will see it's a complete hack with it's heavyweight and lightweight peer scheme.
I have developed a comercial quality application with Xcode/ObjC/Cocoa. XCode and Cocoa deliver.
-
it's a shame...that you are a moron.
2004-02-28 13:45:44 heljen [Reply | View]
It takes a moron to call someone a moron.
There's no royalty fee on using Swing or JDBC. And do you even know what JNDI is?
Sun does charge a license fee for their application server though.
If you're a diehard C or C++ evangelist then I forgive your ignorance. If not, please inform yourself before going hemroid about it.
-
welcome to the world of free software
2004-09-29 21:20:13 aeoe@freeshell.org [Reply | View]
where a 'review' is basically someone hyping a bunch of bullcaca and lying out of their ass. of course, if you ever point this out they will call you a satanic gates worshipping nazi who loves windows. no, you just hate crap software, and thats what most 'free software' (unix) is.
there are a few patterns you can notice about any review of ' free software'. the 'good' items are basically "this feature is a good idea and they have a good start on it" or "this feature is great, and as this is only an alpha version im sure it will be fixed". the 'bad' items are all things like horrible user interface, crashing, etc. the problem here is that unix people, and free software people in general, do not care. they dont care what you think of the UI. their attitude is to tell you to go use windows. now if you say it crashes, they will call you a moron and say you were using it wrong and say 'shrug' it never crashes for them, must be your configuration.
if you point out that other products have good features and dont crash, then they will tell you 'then go use those products, nobody is forcingg you to use this free software'.
if you try to point out that claiming 'this product has feature x' actually implies that the product has feature x, then the linux zealots (im sorry, unix, free software, they are all the same basically) will start screaming at you. you can call it a 'lie'. everyone in the civilized world knows its a lie to promise somethign and not deliver. except in the IT world we know that 'lie' has taken on a special meaning, as has 'promise'. but in unix/free-software 'lie' and 'promise' are useless abstractions. to mention these words is like speaking in cherokee about health care to an audience of chinese cabinet makers at a woodworking convention. the concept of 'lie' and 'promise' are as alien to the world of unix software development as a razor is to richard stallmans face.
thats all well and good. its a free country. you can make horrible products and scream at people for pointing out their flaws, and its a free country.
but apple is a company. they supposedly want people to use their product and they supposedly care about peoples feelings, or at the very least they care about their credibility amongst professsionals who are trying to use their tools.
it is as though merely by using unix, they have allowed themselves to become polluted by the unix ideology of software development: hate users, make half-assed horrible GUIs that crash all the time, and ignore the consequences: the cconsequences being that everyone says 'screw it' and goes and uses Windows instead.
maybe the apple shareholders should read this page, because i am sure the ravneous gnu hippies that have infested Apple are sure as not going to do anything about these problems. they ARE the problem.







Does code completion work in Java projects ? Also, is it extensible ? Is there a documented way to write plug-ins ?