Adobe Unveils Open Source Library
anamexis writes "Adobe premiered (no pun intended) opensource.adobe.com recently. The first two libraries available, titled Adam and Eve, respectively, take on complex GUI issues in applications. They are written in C++ and have been released under the MIT License, an OSI-Approved Open Source License."
If only they'd fix Acrobat Reader for linux...
Not being familiar with the MIT License (too lazy to RTFL), just wondering what use these libraries could be to projects like the GIMP.
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
I was expecting some amazing graphics library but it is just a bunch of fairly trivial C++ templates. Nothing Boost cannot already do.
...But please, release something worthwhile under an open source license, like the backend stuff for Acrobat or something...
And for the love of God, release Reader 7.0 for Linux, and do it soon!
...Searching for "Linux" using the site-only Google search on the opensource.adobe.com website, yields one result: http://opensource.adobe.com/pipermail/pythonphotos hop/2004-January.txt
And that one result no longer exists (you get a 404 when trying to access it). So if any of you folks are preparing to post "Oh boy, that means Photoshop for Linux is just around the corner!" -- you'd better think again.
Simulated Partial Specialization for non-compliant C++ compilers. Allows a user to obtain many of the benefits of partial specialization of C++ templates without direct compiler support.
Python action plug-in for Adobe Photoshop. Allows a user to write Photoshop action plug-ins using Python. Has Python interfaces to all the actions APIs.
Python plug-in for Adobe Illustrator. An Illustrator plug-in adapter that allows users to access the C level API from Python
Python plug-in for Adobe After Effects. An After Effects plug-in that allows users to access the C level API from Python.
Python module for Perforce SCM. A C coded Python module that provides access to all the calls in the Perforce source code management system SDK.
-Don
Take a look and feel free: http://www.PieMenu.com
For the less code-literate among us, what exactly do these files do? Adobe's site doesn't make it clear at all, so R'ing TFL doesn't help...
combined with: "The Eve layout engine has already saved Adobe millions of dollars in localization costs."
Means this contibution (mainly UI work based on Boost) is a very decent contibution.
T.J. Schmitz - the man, the myth, the legend - o
Adobe used the Quorum Latitude Macintosh application porting libraries to port Photoshop to Unix and X-Windows.
The result of using a complex Mac emulation library that mapped quirky Mac toolbox calls onto the byzantine X-Windows graphics model and shoddy Motif/X Toolkit API was an absolutely horrible, ugly, buggy, unusable version of Photoshop. I could quickly cause it to core dump with three clicks of the magnifying glass tool.
Here is a case study of porting Adobe Photoshop to Windows and Unix. It describes some of the reasons Adobe decided to use the Macapp emulation approach for Unix, instead of properly rewriting their code to be platform independent.
Quorum had been around for a while. When I started porting SimCity to Unix in 1991, I evaluated Quarum Latitude, and decided that it was not worth using because my goal was to make a better version of SimCity than the one that ran on the Mac, not a crippled one. For example, I implemented multi-player support via multiple X11 connections to different servers at once, which would have been impossible if the program though it was running on a Macintosh.
-Don
Take a look and feel free: http://www.PieMenu.com
Once GIMP people implement 48bit color and color management, they'll have a potential to take away a large portion of Adobe clientele - web designers and photographers (i.e. people in no way related to prepress and CMYK). When two products have equal capabilities in relation to your tasks, but one is $650 and one is free, the choice becomes really simple.
Right now GIMP is not yet there, but this doesn't mean it'll never be.
From the modules description...
"In the beginning the programmer created the language and the code. And the code was without form, and void; and darkness was upon the screen of the computer. And the programmer moved upon the keyboard of the computer. And the programmer said, let there be Photoshop: and there was Photoshop. And the programmer saw Photoshop, that it was good: and the programmer divided the Command Parameter Modeling Code from the Underlying Framework." - The Book of Photoshop 1:1-4
After reading the full module overview I must say that this looks pretty nice. Note that releasing Adam and Eve won't let every program just take over Photoshop's look and feel (thank god!). You still need to provide all of your own widgets, all of your own event generation code, all your own application back end, as well as write the event handling and layout descriptions. The advantage of this system though, is that the event handling is described cleaning in Adam Expression language which can parsed to execute in any environment. Likewise, the layout can be simplified by describing it in an environment-neutral way that can then be bound to Adam values.
It doesn't seem revolutionary, but it is a nicely worked out evolution in interface building.
"When ideology and theology couple, their offspring are not always bad but they are always blind." -- Bill Moyers
I can't believe these guys are spending all that effort to, in the end, not come up with something better than Mac OS X's AppKit framework (the UI portion of Cocoa).
They're stuck in a static-language, C++ mindset, and so they're designing this huge bloated 'organic' monstrosity of a UI engine, all to avoid the 'inefficiency' of a dynamic language like Objective-C (or Ruby, or Python, for chrissake).
If this is the best they can do, Adobe is dead if only some well-funded competitor wants to come along and stick the fork in.
But then, I think the Boost folks are similarly misguided. Everything they do would be unnecessary in Objective-C, Ruby, or Python, or, if they really want to continue to write in an inscrutable language, just use some obscure Lisp dialect. Boost would then be unnecessary.
Actually, I'd say the quality of Adobe products has declined over the last few years - they've reached that stage where they try to milk the current line for as long as possible, while adding more and more mis-features rather than listening to their customers and splitting out features into different products. Quark in its time was also an innovate company, and look what happened to them...
Personally I find the Photoshop CS menu bar over-crowded, and the Layer Style dialog byzantine (quite apart from the fact it takes an age to open). Double clicking on stuff in the layers palette is also a bit hit and miss - click on the text and you get to edit the layer name, just off the text and it opens the layers dialog. They are suffering a little from featuritis. Compared to The GIMP of course, it's a dream to use.
The File menu in Illustrator CS on OS X now includes the gem 'Save for Microsoft Office' which isn't in the Export menu where it belongs but at the top level - a sure sign that the marketing department has taken over, quite apart from that Online Services... stuff and the recent emphasis on copy protection.
I don't agree that there will be no competition to them - Apple for one have the incentive and resources to create a competitor if Adobe continues their slide towards windows. Already the CS suite are pretty slow on anything but the high end hardware under OS X, because they obviously haven't optimised for UI performance on OS X. A competitor doesn't have to produce a category killer all at once; they can start small and cheap, and build up, as Adobe did with InDesign when competing with Quark. In fact on OS X 10.4, with core image, it wouldn't be too hard to produce a competing product to Photoshop Elements, and build from there.
Having said that, yes Adobe will dominate the professional market for years to come, due to inertia if nothing else - I'm still stuck working in quark under classic for quite a few design clients, who would love to switch to InDesign but haven't yet for legacy/cost reasons : )
Sounds interesting. But that is mostly a problem for something like Windows Common Controls which demand pixel acurate coordinates and sizes. You can easily make an app in, for example, GTK+ 2.0 which has none of those problems. The containers and widgets automagically adjust in size and placement or dimensions are relative. Most GNOME apps, for example, are localized and use a single set of UI code.