[via James Robertson
]: "Can Adobe just port what they have into Objective-C or use Carbon. Unfortunately no, the Flash Player is written in C++ and going from C++ to Objective-C is not very practical. Objective-C is just another superset of C. It simply adds some OOP logic and a messaging and some of the syntax is similar to Smalltalk. You can compile any C program into Objective-C but that's not currently possible to do with a C++ program."
- Emphasis is mine. I can assure you, having done it myself, you can use your current C++ code from Objective-C. I took a collection of pure C++ classes, unmodified, and used them from an Object-C/Cocoa based application. That collection of classes did not have any OS specific code, which made my job easier.
That's not to say Adobe doesn't face a huge uphill climb, it really does, but it can be done. Replacing Carbon with Cocoa is going to be tough. Since they're a cross platform shop I would hope they have a nice set of frameworks that abstract most of the platform specifics from the developer, but that of course is difficult to do. The Photoshop team is in the middle of the Carbon to Cocoa battle
.Bottom line - you can use your C++ with your Objective-C code.
P.S. - I have become a huge fan of Objective-C and Cocoa, I'm just sayin'.
Labels: Adobe, Apple, C++, Cocoa, Objective-C
: "On the other hand, John Nack points out that Flash made video ubiquitous on the web. They do deserve a hat-tip for that, but now that Youtube, Vimeo, BBC and several other sites have standardized around H.264, the de facto future of web video appears to be H.264 "
- If you want to display video it would make sense to create a standalone Flash application for the iPhone/iPod Touch/iPad. Forget the browser for now, focus on writing an app that'll let people view video. Hey, it's a start, and I can't imagine Apple would reject it.
Labels: Adobe, Apple, Flash, iPad
: "I am, at heart, a Web designer, and I came to Adobe to improve the ways software could help design and build Web content. Therefore I'm keenly interested in advancing Photoshop's graphic & Web design chops."
- I would still love to see a fully realized component based model, easier said then done.
Oh, what do I mean by that? I mean creating a generic container application that is then enhanced with components that can operate on a surface. So, if you want a set of vector tools, you install the vector tools, if you want raster tools, you install the raster tools.
Go check John's post. He's looking for feedback.
: "On my iPhone 3G it runs really choppy, on my 3GS it runs acceptably, but it still isn't smooth. Given the OpenGL performance people have seen on the 3GS that is still pretty bad. I have not done any invasive tests by instrumenting the binary, that is just what I can get via basic usage. The sad thing is that there is no reason it has to have performance like this."
- I'm sure we'll see it get better, but, since it is OpenGl it's going to chew on battery. I wouldn't use this for real applications, but it could be a great choice for games. Especially those "one off" games for movie and product promotions.
Labels: Adobe, Development, iPhone, Tools
San Jose Mercury News
: "The San Jose software company, which makes editing, graphic design and Web development tools, said the shutdowns are part of a larger effort to control costs in the face of a global recession. Adobe's sales have declined for the last two quarters, although it still reported $126.1 million in profit on $704.7 million in revenue for the quarter that ended May 29."
- Wowzer, that's interesting news. Apparently it's not the first one week closure this year, nor is it the last. In April Adobe closed for one week and later this year they'll do it again. At least the employees can use their vacation. Sounds all too familiar
Labels: Adobe, Recession
: "In the meantime, I'm seeing quite a few requests for things that Photoshop already does. On one hand I'm always happy to tell people that they can get what they want right now--no waiting, no fee. On the other, it's a bit of a bummer that people don't find features, much less answers, on their own (and we're talking about people savvy enough to find this blog)."
- This is a case of a complex application accidentally hiding features. What are you going to do, Photoshop has been around since the dawn of time, it's the granddaddy of granddaddy's, and the user base is gigantor, so it's very difficult to remove features.
I wonder if Adobe has statistics on the most used features? It would be interesting to see a new application that does that subset of functionality, with a nice shiny new user interface. Then again, maybe applications like Acorn
already do that?
Labels: Adobe, Applications, Indie, Mac
: "Today's Smalltalk Daily looks at Glare, a library for enabling communication between Flex/Air front ends and Smalltalk backends."
- James demonstrates how to create a Flex/AIR based frontend to a backend Smalltalk service, which is cool. Folks do this sort of stuff every day with other languages. But, what if I want to create a Flex/AIR application that runs on the client and lives inside my app, or maybe hosts code I've already written, that does awesomeness AIR can't do? The only way around that limitation today is to open a socket and send "commands" to another application, just like you're doing when you're communicating with a web service. Great for web services, crummy on the desktop.
Adobe could have a killer scripting environment for inclusion into a host application, think VBA, if they would consider moving that direction. Until then it'll fall just a bit short for doing real applications.
For writing real desktop applications today, with cool UI's, in a nice garbage collected, stop the developer from hanging himself, and allows you to use your existing code bases, the choice is clear, Microsoft .NET with WPF.
Adobe I love you, I really, really love you. You're so close, why not go the extra mile and allow existing code to run within your runtime, or allow us to host the AIR runtime within our applications?
Labels: Adobe, AIR, Flex, Smalltalk
NY Times - First Look Blog
: "Next week we'll be introducing Times Reader 2.0. This version is powered by Adobe AIR and will run equally well on Windows , Mac and Linux computers. With this latest release, Times Reader resembles the printed paper even more closely, and it updates every five minutes with the latest news from the Web."
- Here's a great example of AIR done right. The application looks fantastic. Now, question is, will someone go out and create a generic RSS reader that can be crafted to look like this by other newspapers. Then when you subscribe to their RSS feed it also includes some extra bits that tell the reader how to skin
itself so it's branded properly for the newspaper.
I think the NewsGator
folks better get on the ball. Brent
, are you listening?
More on the application at Adobe INSPIRE
Labels: Adobe, AIR, Applications, Technology, Weblogging
Inside Adobe Illustrator
: "You'll see that Von's approach, which is in fact used by many professional Illustrators, is very careful and methodical (in the best sense of these words). Before ever firing up Illustrator, Von has gone through lots of thumbnail sketches, roughs and finally produced a tight sketch that he will scan into Illustrator to use as a template he 'builds vectors'."
- Pencil and paper are still the quickest way to rough out ideas, even when you're doing software engineering. The artist in this case then scans his work to use as a template. Sounds like a good plan.
Labels: Adobe, Graphics, Tricks and Tips
: "Let's say you wanted to create some vectors inside a PSD file. By clicking on the appropriate tool, you could have your PSD remain on screen (but not directly editable) while Illustrator came forward and put you into vector drawing mode. Or you could double-click a bitmap in InDesign or Dreamweaver, then have the image remain on screen while Photoshop comes forward and continues to show the surrounding layout."
- This is the problem Microsoft OLE tried to solve. You could create native objects inside other application document containers then negotiate for "work surface" space, as well as menu and toolbar space. This is how you can embed a Visio drawing inside Word and use native Visio tools to operate on the drawing bits. It was cool back in 1993-94 when we did it, but now it's a bit dated and just feels klunky. I think it would be fantastic if Adobe did this for application suite. A single container that could host native document bits for all their applications, and do the right UI based on the application needed to modify the document. It should feel native all the time. Vector based bits should behave like native Illustrator vectors, raster bits should behave like native Photoshop bits, and they should blend like they are one united document. As John says each Adobe application would just become another component, a big component, but a component none-the-less, that the generic application would know how to load. It's quite brilliant. You could buy the applications like you do today, each would ship with the "loader" application, but if you installed Illustrator and Photoshop you would have one launch point for both apps, and it would be nice if the application component loaded on demand, so if you only wanted to do vector stuff Illustrator would be the only component loaded.
I say it's a great idea, but I'm not your target audience.
First question. Let's say I work for a company that does video security systems and I want to be able to drop my video into an AIR/Flash application, how does one do that?
Second question. Let's now say I have to be in complete control of said video stream? Let's also assume I have a high quality media framework, or pipeline, that does this very thing. It's highly flexible and optimized for receiving, decoding, and displaying video, and audio, and meta-data for that matter. It's crucial to use this existing framework. AIR/Flash video won't do, period.
So, the big question is how do we marry our media pipeline to AIR/Flash? I've asked numerous folks and the answers are always the same. You cannot do that. I'm cool with that answer, but there's always a skeptic among the crowd that believes there's a way to "hack" around things when you're told you can't do it. :-)
One answer may be creating our own video codec? We could write that on top of our framework and do whatever is necessary to insert our video into the runtime as we see fit. Could this be one possible solution?
If you're an AIR/Flash expert that has done this sort of work, I'd like to hear from you. We've gone through so many options that won't work, including Alchemy, I don't believe this is possible to do the way we'd like to do it, but someone may have a way.Thanks!
Labels: Adobe, AIR, Development, Flex, Pelco, Video
: "Today MindJet launched MindManager Web, the online version of the popular mind mapping software. What is cool about it is that it has an identical look and feel to the original MindManager. Actually it makes me wonder when they replace the desktop version with an AIR app."
- I don't get it when people think they can fully replace desktop apps with web apps, even if they're written in Flash/AIR, which is kind of cheating because you're running in a runtime, inside the browser, on the desktop. There are certain things the web is good for, there are other things it cannot replace. A drawing application, especially a really good one, is going to be tough to replace.
Having said that I think the web is great for services and it's super nice when the desktop application can be enhanced by a web service. We did this at Visio with the Find Shape feature. A web service for locating, and downloading, shapes from the web, into the desktop application. It worked quite well and gave you all the power and control of the desktop application.
Web only apps are still not there as a 100% replacement for the desktop, or client applications. Why do you think we have an iPhone SDK? Folks just couldn't do everything they wanted in the browser.
From what I know about AIR it has extreme limitations, some will see those limitations as a feature, which is true in some senses. If you have a HUGE
investment in reusable frameworks, you cannot easily reuse those frameworks inside the AIR sandbox. That, for me, is a show stopper, which is quite unfortunate because it could be a great competitor to Microsoft's .NET if only you could reuse code more easily. Love or hate 'em, Microsoft has always done a great job of bringing old code into their new worlds. We've been able to bring critical frameworks into .NET very easily, and they behave like great .NET citizens.
Labels: .NET, Adobe, AIR, Cross Platform, Development, Flex, Visual Studio
The Flash Blog
: "Ok so those are some of the words that will take on new definitions. There are also terms that will either change or go away completely. For instance, what should I say when I want to refer to the Flash authoring tool? Well stay tuned from Adobe on that one. For now I will specifically either say the version, as in Flash CS4, or just call it Flash authoring. As you may have heard from various sources, Flex Builder may soon be undergoing a name change. This makes total sense as the IDE is used for much more than just developing for the Flex framework. Stay tuned as we continue to roll out new pieces of the Flash Platform re-branding effort."
- I've got to be honest and say, this is super confusing. On .NET Microsoft has done a good job separating terms. The CLR is the runtime , it is the machine. The .NET Framework is, well, the framework you build on top of; access to the OS, Collections, etc. Language terms are clear, we have C#, VB.Net, IronPython, IronRuby, and a host of other languages. We also have an IDE called Visual Studio.
So I could say "I built that on .NET, using C#, and Visual Studio"
. I have no idea how you describe that in the Adobe AIR/Flex/Flash/ActionScript world?
Would it be "I built that on AIR, using ActionScript, and the Flex IDE."
, or something else all together?
I've been mixing AIR and Flex to mean the scripting language all week. I'm fairly certain AIR is equal to the .NET CLR?
Oh, and where does AIR fit into "Flash is being redefined?"
Hopefully we'll get some clear terms from Adobe soon, then maybe my pea brain can understand how everything works together.
Labels: .NET, Adobe, AIR, Microsoft, Visual Studio
I have a question for the Adobe AIR team
, and I certainly hope you can do what I'd like to do.
We have a highly optimized media pipeline we use to display live and playback video. It's highly configurable and adaptable. Pretty obvious given we're a company that develops digital video surveillance systems. We have our own because we need to be in charge of that pipeline. We need to know what's happening and how so we can give our users the best possible experience. The bottom line. It's critical to the success of the product.
Now that we've laid the foundation for the question, here it is. How can I render into an AIR based application and not degrade performance? In a recent release of .NET 3.5 we can do this very thing in WPF, although I'd call it a bit of a hack, it works as expected, and, in general it gives us the performance we're after and makes us a nice WPF citizen.
Are there any technical articles floating around that...
A) Describe how AIR renders.
B) Describes a technique for painting on an AIR surface in a way that doesn't effect AIR performance?
Now, I'm no wilting flower when it comes to rolling up my sleeves and getting dirty. If it means using some Adobe provided API's for rendering, great, point me in the right direction!
My bottom line. I need to be able to render our video into an Adobe AIR application, the way I want, with the performance I expect, otherwise AIR is useless to me for this application.
Thanks for any, and all, feedback.
P.S. - Dear Adobe, don't take that the wrong way. I think AIR is an awesome technology. It just may not be useful for what we want to do. Thanks.
Labels: Adobe, AIR, Flex, Tools, Video
The Unofficial Apple Weblog
: "The bad news might not end there: A tipster with purported connections inside Adobe told us that the company is considering laying off a significant fraction of its nearly 7,000 employees, including management."
- Well I certainly hope not! I know a couple of fellas there, only casually, but it would still stink if this happens. It wouldn't surprise me given how things are going at the moment.John Nack
has been very transparent on his weblog, will he be able to say much about the situation at Adobe?
Enquiring minds want to know, you know?
: "I'm delighted to say that Adobe Photoshop CS4 and Photoshop CS4 Extended, along with the whole Creative Suite 4, are now shipping."
- Congratulations everybody! It's always fun to ship something you've been busting your hump to create, time for a vacation.
: "If you'll be in the San Jose area next Tuesday, Oct. 14, you're welcome to join us for the next meeting of the area Photoshop User Group. Info, pizza, and drinks are on the house, and event details are below."
- I'd love to attend this.
: "I'm a perfectionist, and I deeply, viscerally want to smooth & polish every aspect of Photoshop. Doing it all in any one cycle is impossible, but I'm proud to say we've put a ton of effort into sweating the details in CS4. "
- John has a nice list of new features in the next Adobe CS release.
Labels: Adobe, Applications
: "So, how is the world's most popular 64-bit Mac software built? At the recent Mac-dev C4 conference, Lightroom project lead Troy Gaul presented an inside look at the structure of the application."
- Take a look at the slides. Lightroom relies heavily on the Lua
Very darned cool.
Labels: Adobe, Lua
CNet | The Open Road
: "Columnist John Dvorak thinks that Adobe Systems has a Microsoft problem and that Linux provides a clear solution:"
- This has already been done for Adobe
, it's called Mac OS X
. Now, the one cool thing about this idea is simple. If Adobe developed their own Linux OS we'd finally get a real end-user version of Linux. Do they need it, no, would it make for interesting choice, yes.
If they did it I'd toss out KDE
, and start from scratch, freshly grown shell from the ground up. Keep the kernel and all the nifty hidden stuff. Add real developer tools, Xcode
is a tremendous IDE that makes use of the open source toolchain, gcc and gdb.
Linux doesn't have to be for the hacker only. I work with a few guys, hi Tony and Stuart
, that make Linux sing, but 99% of the population don't care to hop into BASH
and type arcane commands to get what they want. They want to point and click.
With the proper focus, and a world class company like Adobe, they could make it happen. Problem is, it doesn't really make sense for Adobe. They're all about their applications running across OS'es and making money, not creating the OS.
It would sure be fun to work on! But, it doesn't really make sense.
Labels: Adobe, Apple, Linux, Microsoft
: "Over the past few months we’ve had to create a few iPhone mock ups for presentations. The problem we’ve encountered is the lack of resources to help us design something efficiently. Up until now we’ve used a nice PSD from 320480.com but we still found ourselves having to build out additional assets or heavily modifying bitmap based buttons and widgets."
- If you're a Visio user and you need a UI design tool for the iPhone I'd encourage Chris Roth, Mr. Visio Guy
himself, to get to work.
Chris, you could blow this out of the water. Then we need to figure out how to generate the Interface Builder .xib file, and associated handlers. That would be a fun project.
Just having the template for building UI's would be wonderful.
Labels: Adobe, Apple, Graphics, iPhone, Visio
: "Microsoft, Apple, Adobe, and the rest, offer you software that gives them power over you. A change in executives or companies is not important. What we need to change is this system."
- This guy is a complete nut job. He wants to trade paid software for free, why can't we have both? There's nothing wrong with someone making a living writing software and there's nothing wrong with giving your software away. You choose, but quit banging the drum for everything to be free. There's a price to pay for free software as well. I can't hack up Linux and sell it without
making those changes available to everyone, right? Where's the freedom in that? It forces
me to give away the changes that make my system better. That's not freedom, it's a dictatorship. I'm not against free software, I do, however, have a problem with people telling me what I can and can't do.
If Open Source software were truly open I'd be able to distribute it in whatever form I
see fit. I know there are licenses that allow this sort of distribution, but Stallman's idea of open isn't one of them.
Labels: Adobe, Apple, Linux, Microsoft
: "Talking about technical progress only serves to focus attention on the fact that it is Apple’s decision, and by all appearances, Apple does not want Flash on the iPhone. Even if Adobe eventually gets Flash running well — by any standard for “running well” — on actual iPhone hardware, rather than just in the iPhone simulator, they can’t ship it without Apple’s explicit permission."
- I really don't think the iPhone needs
to have Flash support. Apple has gone to great lengths to make sure the experience is what you'd expect from an Apple product. Like the decision not to allow background tasks, I'm OK with that as well. Why? Allowing applications to run in the background comes with its own price. I don't own one, yet, but that will be remedied July 11. I may not have one, but my wife will, and that's essentially like having one myself.
Labels: Adobe, Apple, iPhone
: "We want to make Photoshop and the whole Creative Suite much more flexible, extensible, and connected. Therefore, we're looking at letting upcoming versions of Photoshop and--as far as I know--all Creative Suite applications be extended via SWF panels (palettes) created in Adobe Flash or Flex."
- This would be fun to be a part of. I love doing stuff that allows a product to be extended via third parties. It's fun.
Labels: Adobe, Cross Platform, Development
: "Mark is not going to go work on other digital imaging tools. After 17+ years of driving Photoshop & subsequently Lightroom, he's looking for a complete change of pace & wants to work on operating system technologies related to user experience. Given that Mark has always been a huge Mac guy (developing Lightroom first on the Mac, etc.), it's kind of a Nixon-goes-to-China moment."
- What's bad for Adobe is good for Microsoft. Mark has the opportunity to make the Windows user experience better. With the sad state of Vista, there's nowhere to go but up.
Labels: Adobe, Microsoft
A couple of weeks back I linked to John Nack's discussion of the 64-bit port of Photoshop
, it's not a trivial task, but I'd forgotten you can mix C++ and Objective-C
. This will make it easier for the Adobe crew to port Photoshop, but it's still going to be one heckuva chore!
Here's a VERY simple example. The Objective-C file, main in this case, is using the C++ class named CPPClass. Please note I had to rename the main.m file to main.mm so the compiler would treat it properly. I've also heard you can name the file '.M', or find a specific compiler setting that'll do the same trick for you. I don't know what that setting is, sorry.
Anywho, here's the simple sample.
int main(int argc, char *argv)
CPPClass* c = new CPPClass();
c->Method2("Rob was here");
return NSApplicationMain(argc, (const char **) argv);
Labels: Adobe, Apple, Development, Mac, Objective-C
: "At the WWDC show last June, however, Adobe & other developers learned that Apple had decided to stop their Carbon 64 efforts. This means that 64-bit Mac apps need to be written to use Cocoa (as Lightroom is) instead of Carbon. This means that we'll need to rewrite large parts of Photoshop and its plug-ins (potentially affecting over a million lines of code) to move it from Carbon to Cocoa."
- This is a mammoth undertaking, and quite frankly, I'm not so sure it'll be worth it in the end. It's very rare for a team to sit down, rewrite a gigantor application, and succeed. Why? Think about it for a few minutes. You have a VERY successful product, millions of users worldwide. Those users expect a certain amount of continued support for the product, meaning new features, bug-fixes, etc... So, how do you split your team to deal with that effectively? Now, Adobe may already do that to a certain degree. Two teams, one working on this release, one already exploring and working on the next, then they switch positions, but what about the talk of going from being a Carbon application to a Cocoa application? These are different frameworks, written in two completely different languages. Adobe has a couple of choices here, as I see it, and probable a few I haven't considered. One, they can essentially write their own version of Carbon accounting for just the Carbon features they need, two, they can keep a portable core and write a new Cocoa front end around it. Either way, it's going to be a ton of work. The selfish, techie, side of me says "Yeah, do it, it would be awesome to work on this sort of problem. Go for it!" The reasonable side of me says "Will you sell enough 64-bit native bits to justify the cost? In the end it'll be a business decision and someone will figure out the technical hurdles, that's the way things work in the engineering world. The Sales and Marketing types always ask "Can you do this?" The answer is "Of course we can silly Sales and Marketing people, how much time and money do you have?"
I'm a bit jealous. Whoever works on this is going to have a lot of fun.
UPDATE: John notes the whole Cocoa vs. Carbon debate toward the bottom of the article. If Carbon is good enough for Apple to use in iTunes, it's good enough for anyone else, don't you think?
Labels: Adobe, Development, Mac
: "On this date in 1990, the first version of Photoshop shipped to the world; exactly five years ago we saw the debut of Photoshop's Camera Raw plug-in; and one year ago today, Adobe Photoshop Lightroom 1.0 made its official bow."
- This was a big day in Adobe's history, on many fronts. Worth a read.
Labels: Adobe, Mac, Windows