3 ms·

[Author of the article here] That's an interesting viewpoint, but if I may offer some counter points: By nature, I am a designer. Most of what I do day-to-da

by kneath 17y ago

[Author of the article here] That's an interesting viewpoint, but if I may offer some counter points: By nature, I am a designer. Most of what I do day-to-day involves sculpting the user experience. I know that as much as we want to say that "we have X experience and this is the best way" often times brand new users offer the best insight because they are unfamiliar with your design. A person who has been using XCode for years now has probably grown to ignore the rough spots. Much like you can learn to ignore a train's noise if you live by the tracks. New user's feedback is usually the most valuable feedback you can get. Additionally, I am a huge open source advocate and would gladly help hack and improve upon XCode. Sadly it's not open source. It seems silly to propose that I rebuild, by myself, the 95% of XCode that is awesome in order to improve upon the 5% that needs work. Complaining about a highly extensible open source editor like emacs is indeed just complaining -- just fork the project and implement your code. But choosing to persuade those with power (Apple) to improve upon a product with hundreds of thousands of man-hours already invested instead of rewriting the whole thing myself... well, I'd call that smart programming. I'd also like to point out in the conclusion paragraph, I mention that I am using TextMate for the time being.

demallien 17y ago
I would have found your article far more interesting if instead of ranting, you had undertaken an in-depth analysis of what your workflow actually is, why the current xcode doesn't meet your needs, an explanation of why your workflow can't change to fit in better with xcode, etc. Even better would have been an article where, having analysed the problem, you have come up with a solution. For example, you seem to want a better mechanism for switching between source files in a project. How about a script for xcode that opens up a little search box where you can type in a file name from your current project - it auto-completes the name, and then opens the file? Way faster than clicking on a tab. It'd basically be a copy of the way Spotlight can be used to launch applications - Command-Space, type the first few letters of an app, and hit enter. Done in less time than it takes to reach for the mouse. As a bonus, it doesn't waste screen real-estate on tabs, and can be used to switch even to files that you haven't opened yet. This is the point I was trying to get at in my first post. You're a programmer - this type of script is almost certainly well within your capacities. You could probably generate it in the time that it took to write your article.
- kneath 17y ago
  demallien, I actually did offer a better solution: Xcode needs to implement tabs. As for your script idea, Xcode actually implements this via the "Open Quickly" command, but this doesn't solve any of the issues I outlined in my article. There is a difference between open ecosystems that you can change at will (emacs, vim) and closed ecosystems that you can only change so far as the manufacturer lets you (Textmate, Xcode). To propose I "just write a script" is really to ignore my entire post and it's detailed explanation of why different window management systems work in different climates.

by kneath 17y ago

demallien 17y ago

I would have found your article far more interesting if instead of ranting, you had undertaken an in-depth analysis of what your workflow actually is, why the current xcode doesn't meet your needs, an explanation of why your workflow can't change to fit in better with xcode, etc. Even better would have been an article where, having analysed the problem, you have come up with a solution. For example, you seem to want a better mechanism for switching between source files in a project. How about a script for xcode that opens up a little search box where you can type in a file name from your current project - it auto-completes the name, and then opens the file? Way faster than clicking on a tab. It'd basically be a copy of the way Spotlight can be used to launch applications - Command-Space, type the first few letters of an app, and hit enter. Done in less time than it takes to reach for the mouse. As a bonus, it doesn't waste screen real-estate on tabs, and can be used to switch even to files that you haven't opened yet. This is the point I was trying to get at in my first post. You're a programmer - this type of script is almost certainly well within your capacities. You could probably generate it in the time that it took to write your article.

kneath 17y ago
demallien, I actually did offer a better solution: Xcode needs to implement tabs. As for your script idea, Xcode actually implements this via the "Open Quickly" command, but this doesn't solve any of the issues I outlined in my article. There is a difference between open ecosystems that you can change at will (emacs, vim) and closed ecosystems that you can only change so far as the manufacturer lets you (Textmate, Xcode). To propose I "just write a script" is really to ignore my entire post and it's detailed explanation of why different window management systems work in different climates.