Andrew Noyes's dashboard

You have to use Cocoa to get 64-bit support out of Mac OS X. It's relatively straightforward to bridge from one API to the other; Cocoa applications can be written using many interfaces. You can write a pure Cocoa application using only Ruby, if you wanted to, since there are rapidly maturing facilities to do so. This isn't a matter of Qt providing 64-bit support, but Qt poviding access to the Cocoa framework. It would still require instantial details specific to the Mac platform. Bindings for the Cocoa API make sense if you want to take advantage of Cocoa from behind a "cross-platform" Qt application, but considering that the only door Qt would open to Adobe is simpler (note that I didn't say simple or even easy) paths to porting everything to Linux, which there is not and probably never will be significant demand for. When you're working with a codebase as old and massive as that of the Creative Suite, there is no truly cross-platform solution. Cocoa is a great upgrade path because Objective-C can be mixed with C and C++ compilers, which lets a smart development team layer Cocoa on top of an existing app. Qt wouldn't work as nicely and doesn't offer much. – Andrew Noyes, on December 11, 2009 15:35

Qt is great for writing an app that is relatively easy to port to a different platform, but the Creative Suite is already running on Windows and Mac OS X. The whole reason Adobe is modifying CS to support Cocoa is to get 64-bit support (among other things) on Mac OS X, which Qt wouldn't give them, so there would be absolutely no benefit, aside from making it easier to port CS to Linux, which the company hasn't expressed much (or any) interest in. – Andrew Noyes, on December 11, 2009 13:52

The bookmark comments are handy, but it's standard when working in an environment alongside anyone using Komodo, NetBeans, or Eclipse to find //TODO comments in PHP code. A pane that lists all of these would be helpful!

Thanks for the comment! I agree, some tools are more apt for specific things than Coda. However, I don't really see Coda's FTP philosophy as a hindrance. For one, if you're working on a file that is stored on the remote server, it will update automatically. However, it's merely a difference in workflow. If you're working on local files, you should be either previewing locally, or previewing from a web server running on your local machine. That's why Coda gives you the option to choose a local preview file--otherwise, it would be impossible to preview PHP, Rails, or Django code locally, as they must be processed by the server. Secondly, you should have a separation between your production, staging, development, and local environments. Even if you don't have the full stack, you should have a local environment to work on changes and finalize them before pushing them out to the live server. – Andrew Noyes, on June 15, 2009 16:34

Thanks for the comment! I agree, some tools are more apt for specific things than Coda. However, I don't really see Coda's FTP philosophy as a hindrance. For one, if you're working on a file that is stored on the remote server, it will update automatically. However, it's merely a difference in workflow. If you're working on local files, you should be either previewing locally, or previewing from a web server running on your local machine. That's why Coda gives you the option to choose a local preview file--otherwise, it would be impossible to preview PHP, Rails, or Django code locally, as they must be processed by the server. Secondly, you should have a separation between your production, staging, development, and local environments. Even if you don't have the full stack, you should have a local environment to work on changes and finalize them before pushing them out to the live server. – Andrew Noyes, on June 15, 2009 16:34

Hello Joey,

If you are editing a style sheet, and also have open a preview of an HTML file that links to that style sheet via a <link /> tag, when you edit and save the style sheet, the preview for the HTML file will automatically be updated. While it isn't as nice as CSSEdit's on-the-fly updating, it's not as if you have to manually switch to your browser and hit refresh. However, it is still rather clumsy compared to CSSEdit.

Of course, the only reasonable way to work with this is to split your window yet again and drag the HTML file you want to preview to that third frame. However, you might find it easier to use keyboard shortcuts. I must say that I personally never use with visual CSS editor, but if I did I think I would probably rather use the source editor and visual editor simultaneously by quickly switching using the Command + (1-6) keyboard shortcuts. Command - 2 switches to source edit view and Command - 4 to the visual CSS editor view.

I'm sorry your post has gone unanswered for so long on here! I hope I am of some help.

Thank you very much. I'll be checking up on this so if there's anything I can do to help you in figuring this out, I'd be more than happy to help.

Thanks for the speedy reply Andrea,

No I haven't. I checked that particular configuration. I went through the preferences to make sure there wasn't a reason why it was popping all by its self.

Honestly, nothing that Adobe produces for web development would appeal to Linux users, or even many Mac users for that matter. I don't know anyone who is a serious web developer who would even think about using a product like Dreamweaver to build a website. Don't get me wrong, they exist and their work is not to be devalued, but there is a general disdain of applications like Dreamweaver and competing Microsoft products in the industry because they generally produce crap. As these products advance, this becomes more of a stereotype than reality, but it remains that many web developer prefer granular control over their code. This is doubly so on Linux, where many Linux users are programming gurus and would prefer writing their sites in Bluefish or gedit.

I'm a Mac user and I do most of my web development in Coda, CSSEdit, and TextMate. The only thing bringing me back to Dreamweaver is the fact that on the website we're phasing out at the company I work for, we use Contribute as our CMS.

Wonder-in-a-box products like Dreamweaver don't really appeal to web development studios, which is where the Macs are. Now again, I don't claim to know the general trend of things since there are no statistics on this, but if I had to guess, most people using Dreamweaver are those who are technologically inclined, but don't have the time or resources to invest into building a perfect site. Plus, those not explicitly in the web development industry probably aren't aware of alternatives to Dreamweaver and Expression Web. If I had to guess, the majority of the copies of Dreamweaver being sold AND used are Windows licenses, since the aforementioned companies are overwhelmingly Windows-based.

I like the idea, however I'm worried about how bloated Coda would become with this. Personally, I'm fine using Sequel Pro on its own. Coda is not a complete development environment. There are many web development environments (starts with a D) that try to do it all and fail pretty miserably, drying to be a jack of all trades. Sure, the purpose of Coda is to be one window development, but I think there should be a reasonable cap on what kind of scope that provides. I think being a database manager is outside of this scope.

This type of inspection would be a great improvement, but I would like more to have something like CSSEdit. I remember watching a presentation on Cabel Sasser's blog about how Panic tried to work out an agreement with MacRabbit on CSSEdit but it eventually fell through. Perhaps this is the reason that the DOM inspector in Coda is (relatively) featureless?

Sometimes it's convenient to simply explore the hierarchy of the DOM tree, which Coda's DOM inspector does well, but it doesn't have all the features I would like. The two features I would like to see the most are exemplified in Firebug and CSSEdit 2.6.

In Firebug, the DOM inspector takes you to the code for that element in the HTML code. Also, like the Safari DOM inspector, it shows you which CSS rules are applied to the element. Again, Safari has this, but I like Firebug's better because it doesn't require right-clicking elements to view their location in the DOM tree. You click on an element, and you can quickly see its location in the DOM hierarchy, or the HTML code from which it was generated.

CSSEdit has more what I'm looking for in an integrated environment like Coda. The entire core feature of CSSEdit is to rapidly style web pages without having to refresh the preview. The crux of this is some new features added in CSSEdit 2.5, which allows you to use the X-ray tool (just an inspector) to click on an element, and see which style rules in the actual CSS document are applied to it. Imagine this: two panes in Coda, one of the page preview, and one of the CSS file. You can click on elements with the inspector, and see a panel (Function viewer, maybe?) with a list of the CSS rules from the CSS document that are applied to the element. Clicking on one of those symbols takes you to the CSS rule in the CSS document itself, rather than requiring you to hunt your way through the CSS file.

This would enhance the amount of integration between each of Coda's panes. Coda is phenomenal in for its integration of its constituent apps into one window, but there's very little in the way of integration between those "apps". I think there is a lot of room to streamline CSS development in Coda. Currently, CSSEdit is the only web development app that I use aside from Coda. This type of integration could be expanded by allowing the user to pick a preview page for JavaScript or CSS (read: drag and drop, I'm aware I can type in a URL). If I drag and drop an HTML file from the file browser onto the preview pane, I would like for it to open that page as preview, not open the file in a new tab. It seems silly to have the preview pane by default just spilling the contents of the JavaScript or CSS file into the preview!

Thanks for the great software, and I'm excited for Coda's future!

Thank you very much for the timely response! This is a much anticipated feature. Can't wait for the update!

Best wishes,
Andrew Noyes