One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
- Jamie Zawinski
"The basic rule is that 80% of the people use 20% of the features. So it is not matching feature per feature with photoshop it is matching how well people can access the feature." -jellomizer
"GIMP is also not meant to be like Photoshop and we aren't trying to win PS users over. We are creating a tool that gets the job done. Some approaches of PS are worth to copy, others aren't. GIMP is not a Photoshop clone and it was never meant to be one." -BigSven
"Gimp was not written as a competitor to Photoshop." -mac[LAG]
Please do not compare GIMP with Photoshop, because that's a very sensitive point with GIMP fanatics, who go out of their way to ignore Photoshop, and wear their ignorance as a badge of pride.
Common Lisp is an excellent general purpose programming language.
Since when did you actually get a stack overflow in Lisp, when there wasn't actually a bug in your program? There's nothing about Lisp that causes stack overflows more often than any other programming language. Are you saying that Lisp doesn't permit the stack to grow as much as other languages? That's silly. Are you saying that because Lisp has recursion? Other languages have recursion too, you know.
The interactive programming envorinment and strong debugging tools make Lisp much easier to program, track down and fix bugs in your programs, than other languages.
Powerful interactive Lisp debuggers have been around for decades longer than languages like Java or tools like Eclipse. C++ debuggers like Visual C++ can't hold a candle to Lisp debuggers.
Ever try to symbolically debug C macros or C++ templates? The debugger falls flat on its face and gives you no help! It's because of the fundamental design flaws of C++, that the tools are so weak. Java tools are better because they left out macros and templates, but Java is a much weaker language because of it.
Lisp macros are much more powerful than C preprocessor macros or C++ templates, and it's much easier to cleanly and symbolically single step through and debug them without any of the pitfalls of CPP macros or C++ templates.
Java wasn't designed to be a good language, it was designed to be just a little better than an absolutely horrible language. The same goes with PHP and Perl.
And you know that, how? Were you one of the people reading the code? What open source code have you actually read and reported bugs in?
What's the ratio of the number of people who always say "open source has fewer bugs because more people read it", to the number of people who actually read open source code and report bugs in it?
It's a much better use of your time to actually read open source code and report bugs in it, than to read slashdot and repeat tired old slogans instead.
So what are you doing? Shut up, go read some code, and report some bugs!
PHP and Java are both parasitic to other badly designed languages, but neither of them are particularly well designed themselves. They appeal to people who don't know any better and haven't done their homework researching well designed alternative programming languages.
Java was designed to exploit the fact that C++ totally sucks, and it was successful because frustrated C++ programmers who didn't know other languages liked Java better than C++.
PHP was designed to exploit the fact that Perl totally sucks, and it was successful because frustrated Perl programmers who didn't know other languages liked PHP better than Perl.
Perl and C++ are both horribly designed languages, but neither PHP nor Java are particularly well designed languages themselves. Although Java is a lot better designed than PHP, it doesn't hold a candle to Lisp, which was designed decades before Java.
Oh you have a point there, Sun and the entire computer industry has really turned over a new leaf since 1997. Nobody cheats any more. There are no lessons to be learned from the past.
Tweaking Java test?: Sun Microsystems has been accused of manipulating Java benchmark software and using the results to state that its Solaris "runs Java applications 50 percent faster than Windows NT." Pendragon Software, maker of the benchmark software CaffeineMark, has put out a press release that claims Sun found a way to cheat on the benchmark tests, and then advertised the bogus scores. Sun has since removed the Java compiler from its download page, Pendragon says, but the original press release remains on the Sun site.
Sun Microsystems (SUNW) today conceded errors in the results of recent tests involving its Java programming language.
The company erred in not admitting that it matched code from a Java benchmark tool for one of its own Java compilers, Sun Software president Janpieter Scheerder said today. A benchmark is a battery of tests that measures the speed and performance of software running in various configurations.
Kicking off the "Inside Sun Software Day," Scheerder began his remarks with a mea culpa for Sun's actions, revealed last week in a report by CNET's NEWS.COM. At that time, Pendragon Software, makers of the CaffeineMark Java benchmark test, accused Sun of taking code from the CaffeineMark software and adding it to a beta version of the Solaris 2.6 Java just-in-time compiler. CaffeineMark is one of several developers that have created Java benchmarks.
Last week, Brian Croll--director of product marketing for Solaris, Sun's flavor of the Unix operating system--denied that Sun lifted the code. Today, however, Scheerder made it clear that Sun had made a big mistake.
"Nobody was trying to do anything malicious," Scheerder said. "We just optimized [the Solaris Java compiler] too much."
A Sun public relations manager called the episode a "big-time organizational breakdown" in which an engineering prototype that was never meant to go public was posted on the Web with all attendant documentation, along with a press release that touted the software's performance. Sun has also posted an explanation on its Web site.
"Sun committed an unintentional error when we published Java performance numbers for an engineering prototype that included code that specifically looked for a piece of code in the Caffeinemark 3.0 benchmark," according to a company statement.
In a release dated October 20, Sun bragged that, according to the CaffeineMark 3.0 test, Solaris 2.6 ran Java applications 50 percent faster than Windows NT. But it neglected to say that it had set the compiler to look specifically for a chunk of code from CaffeineMark. Reusing such a large chunk of specific code risks diverting too much of the compiler's resources, resulting in lower performance once the compiler is deployed in the real world, said Ivan Phillips, president of Pendragon.
After taking issue with Sun's test results, Phillips said he asked Sun to retract its claims and remove the compiler from its Web site. As of last week, Sun had not retracted its claims, so Phillips went public with his accusations.
Scheerder stressed today that the compiler, which was part of the Solaris 2.6 Java Development Kit 1.1.4 beta, was not shipping product. The company pulled it from its Web site soon after Phillips contacted them last month.
The news comes four days before the International Organization for Standardization (ISO) decides if Sun is qualified to be the official submitter of Java technology if and when Java becomes an international standard.
The official submitter has the responsibility to gather industry consensus and present it to the ISO's technical committee for consideration. There is some concern that Sun, which owns Java, might not be a neutral submitter. So far, 11 countries have voted yes on Sun's bid and one country--the United States--has voted no. A total of 27 countries are scheduled to vote by Friday.
Developer Quote Of The Week: "What we do is, given a benchmark, we try to do as well as we can on it, and make sure that our system is the fastest benchmark -- I mean, fastest system -- in the world."
-- Brian Croll, Sun Microsystems' director of marketing for Solaris
Two weeks ago, Sun Microsystems got caught with its hand in the benchmarking cookie jar. Or did it? Depending on your point of view, Sun either grossly misrepresented the performance of its Solaris Java just-in-time compiler by fooling Pendragon Software's CaffeineMark performance test, o r Sun proved the CaffeineMark is not an acceptable measure of Java compiler performance.
For those who may have missed it, here's the background: In a Nov. 4 press release, Ivan Phillips, president of Pendragon Software, in Libertyville, Ill., a developer of software for personal digital assistants, accused Sun of engineering its new Java compiler to trick the CaffeineMark into reporting higher performance results.
When Sun's compiler detected a block of 600 bytecodes unique to the CaffeineMark (a technique known as pattern matching), the compiler bypassed data processing, and instead returned a value expected by the benchmark. This fooled the test into reporting performance results 300 times faster than the compiler would deliver in real-world use. Third-party developers subsequently validated Phillips' assertion. Interestingly, when Pendragon's engineers altered the test to appear different to Sun's compiler, the compiler's branching was short-circuited, and its performance plummeted. Java compilers under Windows 95, Windows NT, and the Mac OS delivered uniform results under both the original and altered tests.
Sun officials initially admitted no wrongdoing, and were quick to point out that optimizing software to improve benchmark scores is an accepted practice among computer technology vendors. "People are optimizing against the benchmark," says Brian Croll, Sun's director of marketing for Solaris.
Further, Croll maintained that the aberrant results indicate a fundamental flaw in Pendragon's benchmark suite, and do not represent any impropriety by Sun. "I don't know how valid the [CaffeineMark] is," Croll said. Then last week, during a day-long media briefing at Sun's Mountain View, Calif., headquarters, Sun officials updated their explanation of events. SunSoft president Janpieter Scheerder said the company was not trying "to do anything malicious;" rather, Sun engineers simply "optimized too much."
A Sun spokesperson at the event blamed the incident on human error, and said an engineering prototype somehow found its way through Sun's rigorous (you would think) development and quality assurance processes, and onto the Web, with documentation, and overblown press release in tow.
What if Pendragon officials had not discovered Sun's alleged trickery? What if Sun engineers tweaked their compiler to only improve its score 10-fold, instead of the eye-popping 300-fold increase that flagged Pendragon officials?
Sun's PR machine had already posted a press release, in which they touted their "new Web-enhanced Solaris operating environment" as delivering "the world's fastest Java technology performance." The release also claimed Solaris' compiler was 50% faster than the best Windows NT score, and cited the CaffeineMark as proof.
If Pendragon officials had not discovered the ruse, Sun's formidable sales and marketing machine would now be steam-rolling press and IT decision-makers alike, trumpeting Solaris' performance advantage over Microsoft's Window s NT, waving Sun's illicitly obtained CaffeineMark results as evidence in hand.
"Any benchmark, no matter what its original purpose, is subject to use as 'benchmarketing,'" says Larry Gray, board member of the Standard Performance Evaluation Corp. (SPEC), in Manassas, Va., a consortium that administers many well- known benchmarks. "I'd guess may
Sun Microsystems (SUNW) shrugged off accusations today of unfairly reporting test scores for the beta version of one of its Java compilers.
Pendragon Software yesterday said that Sun, using Pendragon's CaffeineMark benchmarking tool, inaccurately inflated the test results of the Solaris 2.6 just-in-time Java compiler by optimizing the compiler specifically for that test. Solaris is Sun's version of the Unix operating system.
Sun responded by calling such optimization standard practice.
"The idea is that you want people to optimize for the benchmark," said Brian Croll, director of marketing for Sun's Solaris products. "We'll do everything in our power to do really well on all the benchmarks we get our hands on."
A benchmark is a battery of tests that gauges the speed and performance of software running in various configurations. Several developers have created Java benchmarks; CaffeineMark, which Croll called "the best benchmark we've got," is available free off the Web.
But how much optimization is fair play? Pendragon president Ivan Phillips contended Sun inflated the test results of the Solaris 2.6 just-in-time compiler by lifting code from CaffeineMark and inserting it into the compiler.
"The logic test is contained in the 'logicatom.class' file, and almost 50 percent of that file appeared in the compiler," he said. "The probability that this code made its way there accidentally is infinitesimal."
Reusing such a large chunk of specific code risks diverting too much of the compiler's resources, resulting in lower performance once the compiler is deployed in the real world, Phillips added.
Croll denied that Sun used CaffeineMark code but said the company "optimized around it." It will be difficult to determine who is correct, given that the beta compiler in question is no longer available. Croll stressed that the compiler is designed to perform well on a benchmark because that's what determines good real-world performance.
"If certain things happen frequently in a benchmark, you want to make sure you handle them well," he said. "If it turns out the benchmark doesn't truly represent true application performance, you need to evolve the benchmark."
The charges come at a time when Sun and Microsoft are entangled in tit-for-tat lawsuits over Microsoft's use of Java in its Internet Explorer 4.0 browser.
In an October 20 press release, Sun bragged that Solaris had the "world's fastest Java performance" and ran Java applications 50 percent faster than rival operating system Windows NT. After taking issue with Sun's test results, Pendragon said it asked Sun to retract its claims and remove the compiler from its Web site.
Sun removed the entire JDK 1.1.4 for Solaris on October 29 because the beta evaluation period ended, according to Croll. The company didn't take down the press release or rescind its claims, however, and Phillips responded yesterday by publishing his accusations.
Pendragon doesn't usually double-check testers' CaffeineMark scores. But when it saw Sun's results--the Solaris compiler hit a score of 1.4 million on the "logic" test, while the previous high for that test was 22,000--the software firm decided to investigate, fearing that CaffeineMark contained a bug.
If Sun indeed took deliberate steps to skew its results, Phillips was surprised at the lack of subtlety.
"If a company really wanted to conceal what they were doing, they could do a better job," he said.
A: Flex pricing starts at $12,000 for a dual-CPU configuration and includes annual maintenance and Flex Builder. Licenses are available in dual-CPU increments. A free trial edition that converts to developer mode is available for use on individual developer workstations. Annual maintenance includes all Flex software updates, upgrades, and releases for the maintenance period, as well as e-mail-only technical support. In order to help ensure success, Flex customers will also want an annual support contract. To learn more, visit the Macromedia Support Programs page.
Flexible licensing and value pricing options are are available for Flex OEMs and ISVs. Please contact us for more information.
Q: Why does the Flex End User License Agreement prohibit the modification and resale of Flex components?
A: A great deal of the benefit of the Flex programming model lies in its application model. MXML is a language largely defined by the application model and, by design, Flex allows developers to extend, customize, and aggregate components to create new components that work specifically for their applications. However, allowing developers to alter the base components would create a number of subtly different application models, which would lead to MXML skills that do not transfer--not to mention much confusion in the Flex developer community.
Thank you Macromedia for the nice lecture about how prohibiting the modification and resale of Flex components is for my own good.
Laszlo has a huge advantage over Flex: it's Open Source!
SVG is wonderful, but seems to have lost its steam. Adobe has appearently forgotten about it. Batik development has been stalled. SVG has some nice advantages over Flash, but it's hard to beat Flash's 98% penetration. Most people already have it installed, and it works well on small devices. I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.
But now that I've found Open Source Laszlo, programming Flash is quite fun and easy! I can live with that.
If you're interested in Flex, but don't want to shell out huge wads of cash to Macromedia, check out Laszlo, the system that inspired Flex. Laszlo is now Open Source, and it's a wonderful way to program Flash, without using the horrible proprietary Flash authoring tool!
www.laszlosystems.com
The JavaScript pie menus for Internet Explorer support the layout of pure pie menus, pure linear menus, and hybrid menus with both pie and linear items.
They can limit the number of pie items to a default of 8, and the overflow items are put below as linear menu items by default, or you can specify the default direction for overflow items. If you limit the number of pie items to 0, then the menu functions as a normal "pull down" linear menu.
Linear items can also be layed out above, below, to the left, or to the right of the pie menu, so it supports "pull up", "pull right" and "pull left" menus as well as "pull down".
Here is an extreme example of a pie menu with lots of extra linear items in all four directions, that popup up other variations of pie and linear menus. Here is the XML that defines the hybrid pie menu layout.
The pie menus in The Sims are context sensitive, and hide inappropriate items, but the context depends on the state of the object and the selected user, so there are many different contexts which change dynamically over time.
So part of the game is figuring out how to manipulate the objects and people into the right state to enable the menu items you want.
Since The Sims game design requires that the menu items do change over time, that trumps the rule of thumb that pie menus should be used for static menus. User interface design involves weighing conflicting rules and making trade-offs according to the application and user requirements, so it's ok to break a few rules for good reasons.
An inactive TV set just has a "Turn On" menu item. When you activate it, the "Turn On" item disappears and is replaced by a bunch of items like "Turn Off", "Watch TV", "Change Channel," etc.
If you click on another Sim character, you get a menu of interpersonal interactions that the currently selected Sim can perform with the other Sim you clicked on. Those can change according to their relationships and moods.
The Dumbold Voting Machine is a free downloadable Sims object that lets your Sims vote using pie menus.
The voting machine can be in different states: turned off, turned on and booted, and election started and voting. The items on the pie menu change according to the state. It also has other state variables like Printer Enable, Network Enable, Debug Mode, Voter Roll, and the Votes themselves, which you can change by monkeying around with the voting machine.
The items can vary according to the selected character: Each Sim can only vote once (unless some monkey reset the voter roll or left it in debug mode). After a Sim votes, when you click on the voting machine again, instead of getting a pie menu of candidate names, you just get an item that thanks you for voting, and reminds you can only vote once.
Pie menus are easier to use when they have eight or fewer items. But the game design requires that more than eight items be displayed some times.
So pie menus must be able to handle situations with more than eight items, and still be easy to use. The pie menus in The Sims cope with that situation in two ways: overflow items and paging. If you have more than eight items, the overflow items are put above and below the pie menu, so you can select them by pointing at them, but they're not selected as part of the pie. You have to actually move the cursor inside of the label to select the overflow items, while the pie items can be selected anywhere in their wedge shaped slices that extend to the edge of the screen.
If there are even more items than will fit in the top and bottom overflow areas, then it puts the extra items on another page that you can browse by hitting the tab key.
It's obvious how to use the overflow items, but the paging is quite obscure, with no visual indication that it's possible. It is documented in the manual and in faq's, but not many people know about it or use it, because it's rarely necessary.
The paging feature is badly designed and was put in as a last resort, more like an easter egg that can hide the last few items in overpopulated menus. But most menus don't have enough items to require paging (because that's a bad design in its own right), so it's rare that paging is ever necessary. Objects tend to put the most important menu items first, and paging was really only useful during game development when many extra debugging items were enabled.
Note: It's spelled "Fitts' Law", not "Fitt's Law".
You seem to be confused about how Fitts' Law is applied. It doesn't have anything to do with keyboard commands versus mouse commands. It's a way of comparing the speed and accuracy of commands issues by a two dimensional input device like the mouse. It doesn't have anything to do with the time required to switch between different types of input devices like the mouse and keyboard, which is a different issue entirely.
Your argument that Fitts' Law has become unreasonably important doesn't make sense. It has nothing to do with whether or not there are visual shortcuts for keyboard accelerators.
You don't say how mouse gestures will "dramatically change the effects of Fitt's (sic) law". You're putting the cart before the donkey. Fitts' law predicts the dramatic and positive effect of speed and reliability of mouse gestures. It sounds like you're trying to say the opposite. What do you mean?
Your statement that "The more you conform to established metaphores, the more easily you can make your product usable." is pure bullshit, but of course it's true that "Creating new metaphores is difficult, and getting them accepted is even more difficult."
The Sims user interface incorporates pie menus (which Fitts' Law correctly predicts are faster and more efficient than linear menus), but it certainly doesn't confirm to established metaphores. Yet it's the top selling game of all time, and the interface has been reviewed by professional designers as "superb". So yes, it's quite possible to successfully apply Fitts' Law to user interface design, to implement an innovative, easily usable product, without confirming to established metaphores.
In the field of user interface design, you should NEVER make a statement like "At no point should a person be presented with more than 9 items in a selection when one has to be chosen." That's "cargo cultdesign methodology" when you mindlessly repeat rules of thumb without understanting them, trying to imitate the successes of other systems by apeing their surface features, but not understanding their underlying design. User interface design is all about understanding trade-offs and context, not rigidly applying pedantic design rules you read somewhere without understanding them or pausing to consider the actual application.
You seem to be confused about how to apply Fitts' Law. It doesn't have anything to do with keyboard commands versus mouse commands. It's a way of comparing the speed and accuracy of commands issues by a two dimensional input device like the mouse. It doesn't have anything to do with the time required to switch between input devices, which is a different issue entirely.
Your argument that Fitts' Law has become unreasonably important doesn't make sense. It has nothing to do with whether or not there are visual shortcuts for keyboard accelerators.
You don't say how mouse gestures will "dramatically change the effects of Fitt's (sic) law". You're putting the cart before the donkey. The effects of Fitts law dramatically and positively effect the speed and reliability of mouse gestures. It sounds like you're trying to say the opposite. What do you mean?
Your statement that "The more you conform to established metaphores, the more easily you can make your product usable." is pure bullshit, but it's true that "Creating new metaphores is difficult, and getting them accepted is even more difficult."
In the field of user interface design, you should NEVER make a statement like "At no point should a person be presented with more than 9 items in a selection when one has to be chosen." That's "cargo cult design methodology", when you mindlessly repeat rules of thumb without understanting them, trying to imitate the successes of other systems by aping their surface features, but not understanding their underlying design. User interface design is all about trade-offs and context, not rigidly applying pedantic design rules you read somewhere without understanding them or pausing to consider the actual application.
Why does the Apache project strive to produce the best http server in the world, which successfully kicks IIS's ass, while the Gimp project is "just for fun"?
Why does the Eclipse project strive to produce the best Java development environment in the world, that successfully runs circles around the other free and commercial IDE's available, while it's taboo to compare Gimp to Photoshop?
How many of the Eclipse developers have never touched another IDE before, and refuse to look at the competitive commercial products?
Are the Apache, Eclipse and GCC developers into it just for fun, or are they into it because they hate the idea of using software that's inferior to Microsoft IIS, Sun's Java IDE, or Microsoft Visual C++?
Why is it that the Gimp developers are just into it for the fun, and are afraid to compete with Photoshop, when other open source projects have proven not only that it's possible but also extremely practical and rewarding to kick the ass proprietary products?
A full screen mode like Photoshop is a perfectly reasonable request. Don't make excuses and argue with users that they really don't want what they're asking for.
3D Studio Max has scripting via MaxScript, as well as macro recording. Emacs has scripting via Lisp, and both keyboard and Lisp macro recording.
Scripting and macro recording work quite well together, thank you. It's no excuse that having one excludes the need for the other.
Again, you're trying to argue with users and tell them what they want and don't want, which is a bad way to design user interface software.
Pathetic. You're sticking your head in the sand.
It's a classic example of Stallmanesque Software Fanatics cutting off their nose to spite their face.
What is your reason for wimping out about making Gimp easier to use than Photoshop? Are you actually setting your goals lower than Photoshop for a good reason? Why are you so intent on sabotaging Gimp's potential? Are you embarassed to try Photoshop yourself, and afraid to face the fact that it's much easier to use than Gimp?
Don't give me that line of crap about not having access to Windows, not being able to afford Phoshop, and being too politically correct to use a pirated copy. You're just making excuses, and not motivated enough.
If you're developing Gimp (or even evangelizing it), you have a responsibility to figure out a way to learn what Photoshop is all about. Otherwise you're working blind, trying to reinvent the wheel without properly researching the field.
Photoshop has a lot of flaws as well as successes, and you should learn from those, instead of blindly repeating the same mistakes.
"I have even been told that Photoshop does it exactly this way." -Gimp Developer
You mean to tell me that you're a Gimp developer, but you've never used Photoshop?!?!
There's your problem right there. No wonder Gimp is so hard to use.
No user interface designer or software developer should be afraid to use a competing product. It's your responsibility to know Photoshop cold before trying to write something that competes with it. Many of the users you're trying to win over certainly do.
No wonder you're having a hard time understanding why people think Gimp is clumsy and hard to use.
Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.
One thing I like about Brad Meyers is that he's a strong programmer, as well as an excellent researcher, so he had a first-hand understanding of the real-world issues involved in programming languages and user interface architecture, unlike many academics who talk a lot of theory but never get their hands dirty. Brad Meyers understands where the rubber hits the road, and how important it is to have good tires.
At the time I worked on it, Garnet didn't have pretty graphics like Flash, but the underlying programming system had some advanced features that are sorely lacking from most modern user interface development environments.
Laszlo is an modern open source GUI programming system, with many of Garnet's advanced "natural programming" features like prototypes and constraints. Laszlo currently uses Flash as its virtual machine, but it's a much higher level way to program dynamic interactive web based applications, without using the proprietary Flash authoring tool.
Garnet had a true prototype based OOP system (somewhat like Self), which is great for gui programming, because guis have so many objects that look and behave like each other except for a few little customizations (like the layout, graphical style, data source and call-back behavior).
Garnet also had an automatic constraint system, which enabled you to simply define any attribute as a formula that depend on other attributes, without needing to worry about how and when the values were calculated. Garnet's constraint system automatically figured out the dependences of each formula, and automatically and efficiently recalculated and cached any values that needed to be updated, but only when necessary.
With constraints, you can make a button inside a window, and define its left edge to be ((parent.width - self.width) / 2), and it will automatically remain horizontally centered in the window from then on, without you (the programmer) having to worry about what to do when the parent window's size changes.
Without constraints, you have to manually write all the code that changes the button position whenever the window size changes, which results in code scattered all over the place in different classes and handlers and intermediate objects.
Constraints are much easier to use and more general purpose than resize handlers, springs and struts, complex MVC updating schemes, and other Rube Goldberg devices.
Constraints are especially useful for user interface programming, because they save you from having to write lots of annoying boiler plate and error prone code for handling updates (registering, chasing down dependencies, detecting changes, notifying updates, all happens automatically).
Constraints make GUI programming much easier, but they're also useful anywhere in your program where one value is defined in terms of other values that might change at any time.
Once you've tasted a programming language with constraints, you will not want to go back. Programming without constraints is like writing in machine language: error prone, low level, tedious, inefficient and mind numbing.
Constraints are like structured programming for variables: In the same way that it's better to use loops and conditionals instead of gotos, it's also better to use declarative programming that says what you mean, instead of imperative
Slashdot Mirror
Now I realize why X-Windows is still so popular with crappy GUI application developers.
They can blame all their horrible user interface problems on the X-Windows-Manager, so they don't have to bother fixing them.
-Don
From the X-Windows chapter of the Unix-Haters Handbook:
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski
"The basic rule is that 80% of the people use 20% of the features. So it is not matching feature per feature with photoshop it is matching how well people can access the feature." -jellomizer
-Don
According to one of the GIMP developers, BigSven:
"GIMP is also not meant to be like Photoshop and we aren't trying to win PS users over. We are creating a tool that gets the job done. Some approaches of PS are worth to copy, others aren't. GIMP is not a Photoshop clone and it was never meant to be one." -BigSven
"Gimp was not written as a competitor to Photoshop." -mac[LAG]
Please do not compare GIMP with Photoshop, because that's a very sensitive point with GIMP fanatics, who go out of their way to ignore Photoshop, and wear their ignorance as a badge of pride.
-Don
Since when did you actually get a stack overflow in Lisp, when there wasn't actually a bug in your program? There's nothing about Lisp that causes stack overflows more often than any other programming language. Are you saying that Lisp doesn't permit the stack to grow as much as other languages? That's silly. Are you saying that because Lisp has recursion? Other languages have recursion too, you know.
The interactive programming envorinment and strong debugging tools make Lisp much easier to program, track down and fix bugs in your programs, than other languages.
Powerful interactive Lisp debuggers have been around for decades longer than languages like Java or tools like Eclipse. C++ debuggers like Visual C++ can't hold a candle to Lisp debuggers.
Ever try to symbolically debug C macros or C++ templates? The debugger falls flat on its face and gives you no help! It's because of the fundamental design flaws of C++, that the tools are so weak. Java tools are better because they left out macros and templates, but Java is a much weaker language because of it.
Lisp macros are much more powerful than C preprocessor macros or C++ templates, and it's much easier to cleanly and symbolically single step through and debug them without any of the pitfalls of CPP macros or C++ templates.
Java wasn't designed to be a good language, it was designed to be just a little better than an absolutely horrible language. The same goes with PHP and Perl.
-Don
What's the ratio of the number of people who always say "open source has fewer bugs because more people read it", to the number of people who actually read open source code and report bugs in it?
It's a much better use of your time to actually read open source code and report bugs in it, than to read slashdot and repeat tired old slogans instead.
So what are you doing? Shut up, go read some code, and report some bugs!
-Don
Java was designed to exploit the fact that C++ totally sucks, and it was successful because frustrated C++ programmers who didn't know other languages liked Java better than C++.
PHP was designed to exploit the fact that Perl totally sucks, and it was successful because frustrated Perl programmers who didn't know other languages liked PHP better than Perl.
Perl and C++ are both horribly designed languages, but neither PHP nor Java are particularly well designed languages themselves. Although Java is a lot better designed than PHP, it doesn't hold a candle to Lisp, which was designed decades before Java.
-Don
-Don
-Don
Tweaking Java test?: Sun Microsystems has been accused of manipulating Java benchmark software and using the results to state that its Solaris "runs Java applications 50 percent faster than Windows NT." Pendragon Software, maker of the benchmark software CaffeineMark, has put out a press release that claims Sun found a way to cheat on the benchmark tests, and then advertised the bogus scores. Sun has since removed the Java compiler from its download page, Pendragon says, but the original press release remains on the Sun site.
Sun admits Java testing error
Sun Microsystems (SUNW) today conceded errors in the results of recent tests involving its Java programming language.
The company erred in not admitting that it matched code from a Java benchmark tool for one of its own Java compilers, Sun Software president Janpieter Scheerder said today. A benchmark is a battery of tests that measures the speed and performance of software running in various configurations.
Kicking off the "Inside Sun Software Day," Scheerder began his remarks with a mea culpa for Sun's actions, revealed last week in a report by CNET's NEWS.COM. At that time, Pendragon Software, makers of the CaffeineMark Java benchmark test, accused Sun of taking code from the CaffeineMark software and adding it to a beta version of the Solaris 2.6 Java just-in-time compiler. CaffeineMark is one of several developers that have created Java benchmarks.
Last week, Brian Croll--director of product marketing for Solaris, Sun's flavor of the Unix operating system--denied that Sun lifted the code. Today, however, Scheerder made it clear that Sun had made a big mistake.
"Nobody was trying to do anything malicious," Scheerder said. "We just optimized [the Solaris Java compiler] too much."
A Sun public relations manager called the episode a "big-time organizational breakdown" in which an engineering prototype that was never meant to go public was posted on the Web with all attendant documentation, along with a press release that touted the software's performance. Sun has also posted an explanation on its Web site.
"Sun committed an unintentional error when we published Java performance numbers for an engineering prototype that included code that specifically looked for a piece of code in the Caffeinemark 3.0 benchmark," according to a company statement.
In a release dated October 20, Sun bragged that, according to the CaffeineMark 3.0 test, Solaris 2.6 ran Java applications 50 percent faster than Windows NT. But it neglected to say that it had set the compiler to look specifically for a chunk of code from CaffeineMark. Reusing such a large chunk of specific code risks diverting too much of the compiler's resources, resulting in lower performance once the compiler is deployed in the real world, said Ivan Phillips, president of Pendragon.
After taking issue with Sun's test results, Phillips said he asked Sun to retract its claims and remove the compiler from its Web site. As of last week, Sun had not retracted its claims, so Phillips went public with his accusations.
Scheerder stressed today that the compiler, which was part of the Solaris 2.6 Java Development Kit 1.1.4 beta, was not shipping product. The company pulled it from its Web site soon after Phillips contacted them last month.
The news comes four days before the International Organization for Standardization (ISO) decides if Sun is qualified to be the official submitter of Java technology if and when Java becomes an international standard.
The official submitter has the responsibility to gather industry consensus and present it to the ISO's technical committee for consideration. There is some concern that Sun, which owns Java, might not be a neutral submitter. So far, 11 countries have voted yes on Sun's bid and one country--the United States--has voted no. A total of 27 countries are scheduled to vote by Friday.
Developer Quote Of The Week: "What we do is, given a benchmark, we try to do as well as we can on it, and make sure that our system is the fastest benchmark -- I mean, fastest system -- in the world." -- Brian Croll, Sun Microsystems' director of marketing for Solaris
Two weeks ago, Sun Microsystems got caught with its hand in the benchmarking cookie jar. Or did it? Depending on your point of view, Sun either grossly misrepresented the performance of its Solaris Java just-in-time compiler by fooling Pendragon Software's CaffeineMark performance test, o r Sun proved the CaffeineMark is not an acceptable measure of Java compiler performance.
For those who may have missed it, here's the background: In a Nov. 4 press release, Ivan Phillips, president of Pendragon Software, in Libertyville, Ill., a developer of software for personal digital assistants, accused Sun of engineering its new Java compiler to trick the CaffeineMark into reporting higher performance results.
When Sun's compiler detected a block of 600 bytecodes unique to the CaffeineMark (a technique known as pattern matching), the compiler bypassed data processing, and instead returned a value expected by the benchmark. This fooled the test into reporting performance results 300 times faster than the compiler would deliver in real-world use. Third-party developers subsequently validated Phillips' assertion. Interestingly, when Pendragon's engineers altered the test to appear different to Sun's compiler, the compiler's branching was short-circuited, and its performance plummeted. Java compilers under Windows 95, Windows NT, and the Mac OS delivered uniform results under both the original and altered tests.
Sun officials initially admitted no wrongdoing, and were quick to point out that optimizing software to improve benchmark scores is an accepted practice among computer technology vendors. "People are optimizing against the benchmark," says Brian Croll, Sun's director of marketing for Solaris.
Further, Croll maintained that the aberrant results indicate a fundamental flaw in Pendragon's benchmark suite, and do not represent any impropriety by Sun. "I don't know how valid the [CaffeineMark] is," Croll said. Then last week, during a day-long media briefing at Sun's Mountain View, Calif., headquarters, Sun officials updated their explanation of events. SunSoft president Janpieter Scheerder said the company was not trying "to do anything malicious;" rather, Sun engineers simply "optimized too much."
A Sun spokesperson at the event blamed the incident on human error, and said an engineering prototype somehow found its way through Sun's rigorous (you would think) development and quality assurance processes, and onto the Web, with documentation, and overblown press release in tow.
What if Pendragon officials had not discovered Sun's alleged trickery? What if Sun engineers tweaked their compiler to only improve its score 10-fold, instead of the eye-popping 300-fold increase that flagged Pendragon officials?
Sun's PR machine had already posted a press release, in which they touted their "new Web-enhanced Solaris operating environment" as delivering "the world's fastest Java technology performance." The release also claimed Solaris' compiler was 50% faster than the best Windows NT score, and cited the CaffeineMark as proof.
If Pendragon officials had not discovered the ruse, Sun's formidable sales and marketing machine would now be steam-rolling press and IT decision-makers alike, trumpeting Solaris' performance advantage over Microsoft's Window s NT, waving Sun's illicitly obtained CaffeineMark results as evidence in hand.
"Any benchmark, no matter what its original purpose, is subject to use as 'benchmarketing,'" says Larry Gray, board member of the Standard Performance Evaluation Corp. (SPEC), in Manassas, Va., a consortium that administers many well- known benchmarks. "I'd guess may
Sun Microsystems (SUNW) shrugged off accusations today of unfairly reporting test scores for the beta version of one of its Java compilers.
Pendragon Software yesterday said that Sun, using Pendragon's CaffeineMark benchmarking tool, inaccurately inflated the test results of the Solaris 2.6 just-in-time Java compiler by optimizing the compiler specifically for that test. Solaris is Sun's version of the Unix operating system.
Sun responded by calling such optimization standard practice.
"The idea is that you want people to optimize for the benchmark," said Brian Croll, director of marketing for Sun's Solaris products. "We'll do everything in our power to do really well on all the benchmarks we get our hands on."
A benchmark is a battery of tests that gauges the speed and performance of software running in various configurations. Several developers have created Java benchmarks; CaffeineMark, which Croll called "the best benchmark we've got," is available free off the Web.
But how much optimization is fair play? Pendragon president Ivan Phillips contended Sun inflated the test results of the Solaris 2.6 just-in-time compiler by lifting code from CaffeineMark and inserting it into the compiler.
"The logic test is contained in the 'logicatom.class' file, and almost 50 percent of that file appeared in the compiler," he said. "The probability that this code made its way there accidentally is infinitesimal."
Reusing such a large chunk of specific code risks diverting too much of the compiler's resources, resulting in lower performance once the compiler is deployed in the real world, Phillips added.
Croll denied that Sun used CaffeineMark code but said the company "optimized around it." It will be difficult to determine who is correct, given that the beta compiler in question is no longer available. Croll stressed that the compiler is designed to perform well on a benchmark because that's what determines good real-world performance.
"If certain things happen frequently in a benchmark, you want to make sure you handle them well," he said. "If it turns out the benchmark doesn't truly represent true application performance, you need to evolve the benchmark."
The charges come at a time when Sun and Microsoft are entangled in tit-for-tat lawsuits over Microsoft's use of Java in its Internet Explorer 4.0 browser.
In an October 20 press release, Sun bragged that Solaris had the "world's fastest Java performance" and ran Java applications 50 percent faster than rival operating system Windows NT. After taking issue with Sun's test results, Pendragon said it asked Sun to retract its claims and remove the compiler from its Web site.
Sun removed the entire JDK 1.1.4 for Solaris on October 29 because the beta evaluation period ended, according to Croll. The company didn't take down the press release or rescind its claims, however, and Phillips responded yesterday by publishing his accusations.
Pendragon doesn't usually double-check testers' CaffeineMark scores. But when it saw Sun's results--the Solaris compiler hit a score of 1.4 million on the "logic" test, while the previous high for that test was 22,000--the software firm decided to investigate, fearing that CaffeineMark contained a bug.
If Sun indeed took deliberate steps to skew its results, Phillips was surprised at the lack of subtlety.
"If a company really wanted to conceal what they were doing, they could do a better job," he said.
-Don
Q: How much does Flex cost?
A: Flex pricing starts at $12,000 for a dual-CPU configuration and includes annual maintenance and Flex Builder. Licenses are available in dual-CPU increments. A free trial edition that converts to developer mode is available for use on individual developer workstations. Annual maintenance includes all Flex software updates, upgrades, and releases for the maintenance period, as well as e-mail-only technical support. In order to help ensure success, Flex customers will also want an annual support contract. To learn more, visit the Macromedia Support Programs page.
Flexible licensing and value pricing options are are available for Flex OEMs and ISVs. Please contact us for more information.
Q: Why does the Flex End User License Agreement prohibit the modification and resale of Flex components?
A: A great deal of the benefit of the Flex programming model lies in its application model. MXML is a language largely defined by the application model and, by design, Flex allows developers to extend, customize, and aggregate components to create new components that work specifically for their applications. However, allowing developers to alter the base components would create a number of subtly different application models, which would lead to MXML skills that do not transfer--not to mention much confusion in the Flex developer community.
Thank you Macromedia for the nice lecture about how prohibiting the modification and resale of Flex components is for my own good.
Laszlo has a huge advantage over Flex: it's Open Source!
-Don
But now that I've found Open Source Laszlo, programming Flash is quite fun and easy! I can live with that.
-Don
If you're interested in Flex, but don't want to shell out huge wads of cash to Macromedia, check out Laszlo, the system that inspired Flex. Laszlo is now Open Source, and it's a wonderful way to program Flash, without using the horrible proprietary Flash authoring tool! www.laszlosystems.com
That joke was more ironic in the 90's, when I was working at Kaleida (a joint venture of IBM and Apple).
-Don
They can limit the number of pie items to a default of 8, and the overflow items are put below as linear menu items by default, or you can specify the default direction for overflow items. If you limit the number of pie items to 0, then the menu functions as a normal "pull down" linear menu.
Linear items can also be layed out above, below, to the left, or to the right of the pie menu, so it supports "pull up", "pull right" and "pull left" menus as well as "pull down".
Here is an extreme example of a pie menu with lots of extra linear items in all four directions, that popup up other variations of pie and linear menus. Here is the XML that defines the hybrid pie menu layout.
-Don
So part of the game is figuring out how to manipulate the objects and people into the right state to enable the menu items you want.
Since The Sims game design requires that the menu items do change over time, that trumps the rule of thumb that pie menus should be used for static menus. User interface design involves weighing conflicting rules and making trade-offs according to the application and user requirements, so it's ok to break a few rules for good reasons.
An inactive TV set just has a "Turn On" menu item. When you activate it, the "Turn On" item disappears and is replaced by a bunch of items like "Turn Off", "Watch TV", "Change Channel," etc.
If you click on another Sim character, you get a menu of interpersonal interactions that the currently selected Sim can perform with the other Sim you clicked on. Those can change according to their relationships and moods.
The Dumbold Voting Machine is a free downloadable Sims object that lets your Sims vote using pie menus. The voting machine can be in different states: turned off, turned on and booted, and election started and voting. The items on the pie menu change according to the state. It also has other state variables like Printer Enable, Network Enable, Debug Mode, Voter Roll, and the Votes themselves, which you can change by monkeying around with the voting machine.
The items can vary according to the selected character: Each Sim can only vote once (unless some monkey reset the voter roll or left it in debug mode). After a Sim votes, when you click on the voting machine again, instead of getting a pie menu of candidate names, you just get an item that thanks you for voting, and reminds you can only vote once.
Pie menus are easier to use when they have eight or fewer items. But the game design requires that more than eight items be displayed some times.
So pie menus must be able to handle situations with more than eight items, and still be easy to use. The pie menus in The Sims cope with that situation in two ways: overflow items and paging. If you have more than eight items, the overflow items are put above and below the pie menu, so you can select them by pointing at them, but they're not selected as part of the pie. You have to actually move the cursor inside of the label to select the overflow items, while the pie items can be selected anywhere in their wedge shaped slices that extend to the edge of the screen.
If there are even more items than will fit in the top and bottom overflow areas, then it puts the extra items on another page that you can browse by hitting the tab key.
It's obvious how to use the overflow items, but the paging is quite obscure, with no visual indication that it's possible. It is documented in the manual and in faq's, but not many people know about it or use it, because it's rarely necessary.
The paging feature is badly designed and was put in as a last resort, more like an easter egg that can hide the last few items in overpopulated menus. But most menus don't have enough items to require paging (because that's a bad design in its own right), so it's rare that paging is ever necessary. Objects tend to put the most important menu items first, and paging was really only useful during game development when many extra debugging items were enabled.
-Don
You seem to be confused about how Fitts' Law is applied. It doesn't have anything to do with keyboard commands versus mouse commands. It's a way of comparing the speed and accuracy of commands issues by a two dimensional input device like the mouse. It doesn't have anything to do with the time required to switch between different types of input devices like the mouse and keyboard, which is a different issue entirely.
Your argument that Fitts' Law has become unreasonably important doesn't make sense. It has nothing to do with whether or not there are visual shortcuts for keyboard accelerators.
You don't say how mouse gestures will "dramatically change the effects of Fitt's (sic) law". You're putting the cart before the donkey. Fitts' law predicts the dramatic and positive effect of speed and reliability of mouse gestures. It sounds like you're trying to say the opposite. What do you mean?
Your statement that "The more you conform to established metaphores, the more easily you can make your product usable." is pure bullshit, but of course it's true that "Creating new metaphores is difficult, and getting them accepted is even more difficult."
The Sims user interface incorporates pie menus (which Fitts' Law correctly predicts are faster and more efficient than linear menus), but it certainly doesn't confirm to established metaphores. Yet it's the top selling game of all time, and the interface has been reviewed by professional designers as "superb". So yes, it's quite possible to successfully apply Fitts' Law to user interface design, to implement an innovative, easily usable product, without confirming to established metaphores.
In the field of user interface design, you should NEVER make a statement like "At no point should a person be presented with more than 9 items in a selection when one has to be chosen." That's "cargo cult design methodology" when you mindlessly repeat rules of thumb without understanting them, trying to imitate the successes of other systems by apeing their surface features, but not understanding their underlying design. User interface design is all about understanding trade-offs and context, not rigidly applying pedantic design rules you read somewhere without understanding them or pausing to consider the actual application.
-Don
You seem to be confused about how to apply Fitts' Law. It doesn't have anything to do with keyboard commands versus mouse commands. It's a way of comparing the speed and accuracy of commands issues by a two dimensional input device like the mouse. It doesn't have anything to do with the time required to switch between input devices, which is a different issue entirely.
Your argument that Fitts' Law has become unreasonably important doesn't make sense. It has nothing to do with whether or not there are visual shortcuts for keyboard accelerators.
You don't say how mouse gestures will "dramatically change the effects of Fitt's (sic) law". You're putting the cart before the donkey. The effects of Fitts law dramatically and positively effect the speed and reliability of mouse gestures. It sounds like you're trying to say the opposite. What do you mean?
Your statement that "The more you conform to established metaphores, the more easily you can make your product usable." is pure bullshit, but it's true that "Creating new metaphores is difficult, and getting them accepted is even more difficult."
In the field of user interface design, you should NEVER make a statement like "At no point should a person be presented with more than 9 items in a selection when one has to be chosen." That's "cargo cult design methodology", when you mindlessly repeat rules of thumb without understanting them, trying to imitate the successes of other systems by aping their surface features, but not understanding their underlying design. User interface design is all about trade-offs and context, not rigidly applying pedantic design rules you read somewhere without understanding them or pausing to consider the actual application.
Why does the Eclipse project strive to produce the best Java development environment in the world, that successfully runs circles around the other free and commercial IDE's available, while it's taboo to compare Gimp to Photoshop?
How many of the Eclipse developers have never touched another IDE before, and refuse to look at the competitive commercial products?
Are the Apache, Eclipse and GCC developers into it just for fun, or are they into it because they hate the idea of using software that's inferior to Microsoft IIS, Sun's Java IDE, or Microsoft Visual C++?
Why is it that the Gimp developers are just into it for the fun, and are afraid to compete with Photoshop, when other open source projects have proven not only that it's possible but also extremely practical and rewarding to kick the ass proprietary products?
-Don
3D Studio Max has scripting via MaxScript, as well as macro recording. Emacs has scripting via Lisp, and both keyboard and Lisp macro recording.
Scripting and macro recording work quite well together, thank you. It's no excuse that having one excludes the need for the other.
Again, you're trying to argue with users and tell them what they want and don't want, which is a bad way to design user interface software.
-Don
Pathetic. You're sticking your head in the sand. It's a classic example of Stallmanesque Software Fanatics cutting off their nose to spite their face.
What is your reason for wimping out about making Gimp easier to use than Photoshop? Are you actually setting your goals lower than Photoshop for a good reason? Why are you so intent on sabotaging Gimp's potential? Are you embarassed to try Photoshop yourself, and afraid to face the fact that it's much easier to use than Gimp?
Don't give me that line of crap about not having access to Windows, not being able to afford Phoshop, and being too politically correct to use a pirated copy. You're just making excuses, and not motivated enough.
If you're developing Gimp (or even evangelizing it), you have a responsibility to figure out a way to learn what Photoshop is all about. Otherwise you're working blind, trying to reinvent the wheel without properly researching the field.
Photoshop has a lot of flaws as well as successes, and you should learn from those, instead of blindly repeating the same mistakes.
-Don
You mean to tell me that you're a Gimp developer, but you've never used Photoshop?!?!
There's your problem right there. No wonder Gimp is so hard to use.
No user interface designer or software developer should be afraid to use a competing product. It's your responsibility to know Photoshop cold before trying to write something that competes with it. Many of the users you're trying to win over certainly do.
No wonder you're having a hard time understanding why people think Gimp is clumsy and hard to use.
-Don
One thing I like about Brad Meyers is that he's a strong programmer, as well as an excellent researcher, so he had a first-hand understanding of the real-world issues involved in programming languages and user interface architecture, unlike many academics who talk a lot of theory but never get their hands dirty. Brad Meyers understands where the rubber hits the road, and how important it is to have good tires.
At the time I worked on it, Garnet didn't have pretty graphics like Flash, but the underlying programming system had some advanced features that are sorely lacking from most modern user interface development environments.
Laszlo is an modern open source GUI programming system, with many of Garnet's advanced "natural programming" features like prototypes and constraints. Laszlo currently uses Flash as its virtual machine, but it's a much higher level way to program dynamic interactive web based applications, without using the proprietary Flash authoring tool.
Garnet had a true prototype based OOP system (somewhat like Self), which is great for gui programming, because guis have so many objects that look and behave like each other except for a few little customizations (like the layout, graphical style, data source and call-back behavior).
Garnet also had an automatic constraint system, which enabled you to simply define any attribute as a formula that depend on other attributes, without needing to worry about how and when the values were calculated. Garnet's constraint system automatically figured out the dependences of each formula, and automatically and efficiently recalculated and cached any values that needed to be updated, but only when necessary.
With constraints, you can make a button inside a window, and define its left edge to be ((parent.width - self.width) / 2), and it will automatically remain horizontally centered in the window from then on, without you (the programmer) having to worry about what to do when the parent window's size changes.
Without constraints, you have to manually write all the code that changes the button position whenever the window size changes, which results in code scattered all over the place in different classes and handlers and intermediate objects.
Constraints are much easier to use and more general purpose than resize handlers, springs and struts, complex MVC updating schemes, and other Rube Goldberg devices.
Constraints are especially useful for user interface programming, because they save you from having to write lots of annoying boiler plate and error prone code for handling updates (registering, chasing down dependencies, detecting changes, notifying updates, all happens automatically).
Constraints make GUI programming much easier, but they're also useful anywhere in your program where one value is defined in terms of other values that might change at any time.
Once you've tasted a programming language with constraints, you will not want to go back. Programming without constraints is like writing in machine language: error prone, low level, tedious, inefficient and mind numbing.
Constraints are like structured programming for variables: In the same way that it's better to use loops and conditionals instead of gotos, it's also better to use declarative programming that says what you mean, instead of imperative