Integrating OSS Graphics Apps
erikharrison writes "Newsforge had an article recently which proposed an interesting way to make an integrated OSS graphics "suite" - namely, get existing apps to standardize their look and feel. Now, in a short and insightful article, Bryce Harrington (of Inkscape fame) responds with specifics on the advantages and problems with this approach, and where development should go next in the pursuit of a complete OSS stack for graphic artists."
I don't know what the question is, but SVG is obviously die antwort.
I'd be happy if software could standardize on copy and paste key sequences.
Is getting the GIMP's UI to standardize on "NOT SUCKING"
Get back to me when you've gotten somewhere with that
P.S. Repeating "you're just not used to it" doesn't make UI problems go away. If you can't use a program until you learn to overlook its idiosyncrasities, that's pretty much the *definition* of a bad interface
Each person makes the best possible tool for the application and not stifle creativity or new solutions to the UI by trying to make things "marketable" as a package.
If it's good, users will use it. If it's not, making it part of a suite won't guarantee that they will.
And I see a Newsforge banner ad just for that right above the article. Now that suggestion will stick for a while on the front page :)
The lack of pantone compatibility is a major roadblock. I suggest that the OSS design apps create an open palette plugin format, which would allow users to create and to load in palettes. Then some enterprising soul, who would of course have no connection to the apps themselves, could create a pantone-compatible plugin, which could be downloaded separately from the apps.
This is similar to what happens in the audio world with mp3 encoders.
This newsforge article is directed at the community. That's nice.
The community isn't who needs to hear this. The community already uses these OSS graphics apps.
The people who a suite like this would appeal to are people outside of the community-- people who shop at wal-mart.
The people who need to hear this are businesses.
If some company could have the foresight to gather together the OSS graphics apps, clean them up, tie them together make their interfaces consistent with Mac OS X and Windows UI guidelines, put this all in a nice pretty box, and sell it for $30 at Wal-mart, there's a decent chunk of cash to be had in this. The fact the OSS community has already done all the hard work in developing these applications means you'd be able to offer a very attractive package for a discount-rack price. And the people who would buy something like this wouldn't know how to download and compile software themselves if they wanted to, so they won't mind they're paying for GPLed software.
Just a thought.
Never (hopefully). Photoshop has a wonderful interface based on L hand on the keyboard and R hand on the mouse. I like it, artists like it, and it works a hell of a lot better than any other complex raster graphics program that I know of.
=)
"You know why you do not see me styling wit my homies? Because I have no homies!!" -Mojo Jojo
So you have only one finger on your right hand or why do you need another hand to press a second mouse button?
Linux is not Windows
It confuses it mentally. Anything too confusing to use drunk will not fly with the art crowd. And in general, artists do not think like geeks do.
He even addresses the issue you are berating him for. From the article (titled "Achieving higher consistency between OSS graphics applications"):
-- This post (c) 2003, Knights who say Ni, LTD.
As a frustrated Linux only user, I'm with you. I started in imaging using the gimp and ended up raised thinking it was MEANT to be hard working with pixels.
After years with GIMP I used Photoshop (my sister has a Powerbook). If there's ever a poster boy for the advantages of proprietary software it's photoshop. It's a dream to use, and for the work I do so much faster on smaller hardware than my gimp box. It uses RAM like nobody's business, but then I buy my hardware in the expectation the software will make use of it.
Now I'm still stuck with GIMP on my own box, and finding it harder to justify my use of it by some kind of moral & price advantage when it's really stifling my need for it to work as a graphic tool.
Consistency is a valid goal in (almost) anything.
B ecause if you're not consisten
t then usability is affec ted
and people won't
even
rea d this
f
a
r, I believe
You can't talk about Wikipedia's flaws on Wikipedia
How about some people make the best possible tool for the application and does not stifle creativity or new solutions to the UI by trying to make things marketable as a package.
And some other people take the tool the first people made and, while leaving the first group off alone and free to exercise their creativity, make it marketable as a package.
That's the strength of OSS development, it can do more than one contradictory thing at once...
...namely, get existing apps to standardize their look and feel.
...so they can just copy exactly what some other program is doing, and the OSS designers don't have to be innovative or creative on their own? Come on now, do you own work...
Why would you want a standard interface anyway (No, I didn't RTFA)?? That would be absolutely horrible if any major (or even minor) advances, tweaks, changes, etc are made... you're still stuck in an outdated "standard" that probably won't apply to whatever you came up with. Even if you update the "standard", that's just wasting needless time.
So far, I've been a huge Linux advocate/fan/user.
I'm getting somewhat disillusioned about the lack of project planning / management. I see the community trying to implode upon itself, mired in political crappiness.
If Linux is going to supercede Microsoft (the community has obviously better code at times), the community has to out-do the project management abilities that Microsoft has.
Where "not sucking" means "actually honestly evaluating UI issues and actively addressing them where necessary, instead of responding to every complaint of any form with 'you just want photoshop you're just not used to it la la la'"
You know, just basically considering interface design to be the developers' problem, not the users'
As I recalled, the WYSIWYG HTML editor generates a lot of bloated codes. Does the same thing happen on drawing apps exporting SVG format? If I include raster objects in SVG document, will Inkscape/GIMP include them as the bloated mime-64 strings, or do they save them in XOP?
When these apps use standard data formats and simple IPC, we can write our own GUIs (or CLIs) and make them look like they're integrated. Without standard interop, they never will.
--
make install -not war
1. CMYK and LAB color mode support in GIMP
2. Complete color management support throughout the app
3. High bit depth graphics support - 48 bit and floating point (to stay a bit ahead of Apple/Microsoft).
That's all I want. I couldn't care less about how things look and feel if they do what I want. Well, at least if we're not talking about Mac apps, where look and feel are more important.
The competition from Adobe and Macromedia is already tremendously robust on a level that in a 1:1 competition between say GIMP and Photoshop that the OSS apps can scarcely approach the level of functionality that their commercial competitors can. We are talking about very well-financed, extremely aggressive competitors here, not lumbering monoliths that can only succeed half the time by pulling on past successes.
It's worth doing, but no one should get their hopes up that Adobe or Macromedia will be phased by this. They are simply too good at what they do to be caught up in the same software vietnam that Microsoft has found itself in with Linux, Apache, OpenOffice and Mozilla.
Click here or a puppy gets stomped!
We'll never have very rigid standards in anything OSS because, I believe, programmers let their egos get in the way of creating the most usable program possible. They resent the notion of someone telling them how their project should function, and offen interpret any feedback as an attempt to stifle their creativity.
A lot of people like doing things their way, and that's fine! But when we see such fragmentation, forks, redundancy, etc. in OSS projects, we can't be surprised when interoperability is next to impossible.
So if you need to make your project work in a way that only you want it to work, don't be surprised when nobody else uses it.
Socialism: A feeling of discontent and resentment caused by a desire for the possessions or qualities of another.
Use the proper control for the task, and don't clutter your windows. Example: Don't use 2 radio buttons when one checkbox would suffice, don't use more than 5 radio buttons when a combobox would work better.
Also - for God's sake - LINE UP YOUR CONTROLS. If you're a Windows Developer, whether it's VB/C/C++/C#, it's just a matter of laziness to not align your controls. If you're using Java - use a layout manager or a number of layout managers. If you're using GLADE or QtDesigner, take the extra 3 seconds to line up your controls.
Also, tab order should be logical. Focus should go left to right, top to bottom (Arabic and Hebrew - see above). You should also support keystroke shortcut keys that make sense, in fact, if you can make them user definable - do it. Not everyone uses a Qwerty keyboard, and not everyone uses the US character map. Don't make the user move his or her hands unless necessary. Also, right click (or Ctrl-Click) context menus are great - use them.
Finally, some people prefer SDI style apps (OpenOffice.org, IE), others prefer dockable MDI style apps (Visual Studio), and some prefer a collection of floating windows (GIMP). Internally, it's all the same, just each window has a different parent - provide the option to your user. Organize your code properly to handle this from the beginning..
Also - don't pick a color scheme - let the system color it. Same for fonts - that red and green text might look pretty nifty, but to a colorblind person there's no discernable difference. In fact - don't use specific colors at all to convey status. Here in the States, Red means Stop, but this is not true in all cultures. Plus... some people are colorblind. Changing an indicator from green to red is meaningless to them.
This really should be common sense, but I can't tell you how much GUI stupidity I've fixed in my career. Most of it can be attributed to 2 things: laziness, and the GUI done as an afterthought. This is a problem, because while your code may kick all kinds of ass under the hood, if your GUI looks like it was done during amateur hour at the YMCA, the user will think the rest of your app is just as bad.
Also, don't be afraid to consult a graphic designer about your user interface, especially when it comes to icon selection. They excel at conveying that kind of information. Chances are, you have at least one in your marketing department.
If I find an application worth using, it seldom has to do with the UI in itself. Tabbed browing as an example is nice, but if that ment that I would have a list widget to the left instead, that would work as good for me, maybe even better when you think of what you can do with it.
Unified GUI's are just another way of saying "we're not like them". But we are not like the others, and that's why linux is good to begin with. I think people are trying to figure out ways so that linux will be more popular amongst windows users, but I don't think it has anything to do with the GUI.
Let GUI's evolve and the featureset and usability will gain from it, with KDE and Gnome everything kinda looks the same anyway.
And if you're developing OSS for windows only, yeah, have it your way, because then I don't really care.
Albert
This is a huge issue and addressing it so openly is a very GoodThing(tm). To work between these apps is technically doable now, but improving the consistancy between the apps lets them become tools and not just exersises for programmers to work on. Artists don't want to think about what keystroke does what, they want to have it become second nature so that they can use all that mindshare on making art. The discussion of having community standards created to drive these standard interfaces will do a lot to help artists feel like "if I learn these new rules they will still work in the future and will work with all of the other apps I need". which is one of the reasons why users of applications do not migrate to every new app that someone comes up with. Until users feel like the effort will be worthwhile, they will not migrate. When you are thinking about how to structure your composition on an art piece, the most frustrating thing in the world is to have to break your concentration to go google for how this one tool works in comparison to the same tool in another app you are used to. I am VERY hopefull for this effort.
Real Men use ImageMagick!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Wish lists are nice. They let developers know what features they want in a particular project. However, to paraphrase the Wesnoth dev team, "we wrote the program the way we did because that's how we like it. If we use some of your suggestions, it's because we like those, too." These folks write code to scratch their own itch. Scratching YOUR itch is merely a by-product.
Yes, software use and usability is a good thing, but in the end, it comes down to whether coders want to implement it or not.
Cloning: most "users" have a reference point when they use software. People used to windows will find a mac interface foreign and "wrong." Photoshop users will start out not being used to how GIMP works. Same with Word users and OO.org -- just the nature of the game. The real question is: do we have to clone popular interfaces? I suppose. At least maybe some sort of "Photoshop Interface" toggle. Then again you can be a smug developer and say "Use it or not. Go 'way."
Integration: While we're making a list, here's mine:
I want a Quanta that integrates to GIMP which supports editable text mask layers, editable bevel/embossed layers, and that whole color management thing. Integrate that with a managed FTP client thingy kinda like Screem advertises, too. Oh, and integrate that into something that can do Flash animations, too...which will dynamically embed itself onto a Quanta-generated xhtml-valid page. And and and I want a pony!!!
The integration idea is nice. I suppose there's an argument to be made to integrate now and polish later but I think the focus is to make each individual part work well first, then consider integrating later.
Some things need standardization, others should have it, and then there are things that shouldn't be standardized simply because it isn't necesary in the least bit. If you want to use a program, you will learn how the UI interacts no matter how abstract it is.
-Mike
Photoshop works fine in WINE. So you really aren't tied to the GIMP if you don't mind paying for Photoshop.
I am assuming you have a x86 Linux computer of course.
Comment removed based on user account deletion
I find photoshop is only steps behind GIMP on a bad interface; I like the Jasc Paint Shop Pro interface but as they've add more features it has gone down hill.
Why would you want a standard interface anyway?
Try asking any Apple user.
Do you really think that people will click that link when hovering over it shows the URL is "http://minigirls.biz.nyud.net:8090"?
As far as integration goes, I think it would be a good idea for a company like Red Hat or Novell to step in and sponsor a port of Scribus to Gnome. Some really interesting things could be done when Inkscape, the Gimp and Scribus are native Gnome apps.
This has nothing to do with KDE. Its just that the other two productivity apps mentioned (the Gimp, Inkscape) already run on Gnome, as do most other best-of-breed Linux applications. Don't get me wrong, better integration between KDE and Gnome is a good thing, but there is no harm in porting some of the most popular apps to the other platform is that fills a void. After all, this is open source, and porting Scribus (clearly an excellent app) should be much easier than porting Windows apps to Macintosh.
As a professional artist and MFA candidate, I can say that there are a few things I'd look for in an OSS suite:
1. It can open photoshop, illustrator, and quark Xpress formats. You wouldn't be surprised how many people use those formats...
2. I agree with standard cut+paste, and I would go further to say standardized "layers", and at least the buttons looking similar, i.e. a little paintbrush is the standard paintbrush-type feature, not some random crap in one place and some other random crap in another place.
3. Cross-application automation throughout the suite. A lot of regular graphics tasks are repeated a ton of times, and if I could: scan in a document, auto-level it, crop whitespace, and generate a thumbnail, that would majorly cut down on the time it takes me to get a new artwork online.
4. Way easier to customize elements. I'd love to make my own brushes & effects a bit easier and consistently, but I know that's tough.
stuff |
good point, either drunk on alcohol or high on some hallucinigenic drug. Either way if you put something there with a right click, and they meant to do a left click but hit the wrong button... they might freak out and jump of a bridge, and we already know how high the suicide rate among artistic types is.
Close to 1 year ago, I conducted an extensive test of clipboard compatibility between the major Free Software desktop applications. (OpenOffice, Mozilla, KDE Office, Abiword, Gnumeric, and The Gimp). Scores were dismal, especially for The Gimp, which usually appeared to be using a clipboard system completely disjoint from the other applications.
Quick retests conducted today, using the newer 2.0 GIMP series, show tremendous improvement.
Today, The GIMP is capable of accepting graphics pasted from Kword, OpenOffice.org, or Abiword. And material copied from it can be pasted into Kword or Abiword.
The GIMP's new recognition of X11 clipboard protocols is a major step forward. (There is no excuse that it took so long, though)
More, importantly, when will Gimp and Photoshop abandon their useless right-click crap and just do the sensible Paint Shop Pro thing of reversing the Foreground/Background colours of the command when it's issued with the right mouse button?
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
I think this was the most insightful comment on FOSS interoperability I have read in a long long time. It is refreshing to read an opinion that does not focus on language and toolkit differences. Even though - the suggestion for projects to develop sharable building blocks in the form of reusable APIs is very good. I think that is a slow, but certain way to increase interoperability over time - between the subset of applications developed with the same language.
If these APIs then work against common specifications, such as SVG or something that is developed together between several projects, a lot is gained.
It is more important to have applications sharing common patterns of usage than sharing the same toolkits. Keyboard shortcuts is an excellent example of something that can be shared independently of the programming language. Fonts, icons and color themes as well. I believe "consistency" in the form of sharing a common toolkit, is not the holy grail.
Compare with the web - there are thousands, if not millions, of online retailers. Most of the webshops share common usage patterns. Most have shopping baskets, which you can add items to by clickling a button. The buttons for adding things to the basket do not look the same beween sites, and neither does the shopping basket icons, yet millions of people manage to buy things online.
That just means that either you don't know about the better working methods that can be found elsewhere, or you don't know how to use them very well. No big deal. That simply says you're in the same boat as most other Photoshop users, not that you're a sub-standard graphics person.
There are definitely better ways to work than "the Photoshop way." Better because they are faster, more efficient, more precise, more flexible. Then again, Photoshop is what people are used to, and that is the key here -- not that it is UI perfection, but that it is pervasive and for many tasks, it is more than good enough. Habit counts here as well.
A couple of months ago, a friend of mine who is really a pretty expert Photoshop user, was working on an old photo. He was using the healing brush and the clone (pantograph) tool to fix the thing, and he was definitely getting it done. It seemed quite slow to me, because I don't do it that way -- I use something more efficient. I knew he had the other tool on his system, so I got him to start it, popped the image in there, and got the entire healing job -- the complete scratch, which he hadn't yet finished after several minutes -- done with one area selection that took about 2 seconds to complete. I explained how it worked, and why, and his reaction was "wow", but you know what? The next day, I found him back in Photoshop, fixing a different scratched image (these are scans of very old family photos, lots of damage.) I asked him why he wasn't doing it the way I showed him, and looked kind of guilty and said "This is warm and fuzzy... I'm comfortable doing it this way." I just said "cool" an walked off. I think that says a lot about who uses what, and why. This guy is bright, skilled, and generally pretty open minded. But then again, he's very "comfy" with Photoshop and that directs his actions to a very large degree. I don't think this is unusual, either.
On the other hand, if we're going to talk about maximum potential efficiency, that is, how fast a particular task can be done to an equal degree of precision given two diverse approaches, for many tasks Photoshop's one-mouse-button approach falls short of other mechanisms -- this is also the case with some other UI issues and technical capabilities it has (or doesn't have) that are lacking in efficiency and flexibility.
These things typically aren't a big deal unless maximum efficiency and flexibility and speed are issues; if they are, then it is worth some time to look elsewhere. There are some advanced UI approaches out there, several of them quite interesting and useful. And definitely faster.
If you like painting with brushes made of images, then there are some cool tools out there that leave PS in the dust. Which ones might surprise you if you've spent most of your time with Photoshop. If you are a "Master Layer Blending Person" then there are far more advanced image layering systems out there. If you like writing plug-ins, there are easier to develop for plug-in interfaces that provide some really neat things and are far easier to write to. If you are really into efficiency, there are definitely better ways to utilize the mouse. If you are into scripting, there are custom BASIC, python, and "other" script-driven interfaces in some of the other packages that are really quite complete and powerful. There are systems that handle deeper bit-depth images more completely, or consistantly, and there are systems that do more flexible color separations (try mixing UCR and GCR approaches in Photoshop and I think you'll see what I mean about flexibility.)
Photoshop is great. No question about it. But it is not the be-all and end-all of graphics software. It is just the most popular. Part of that is functionality, but another part of it is marketing and simple user enthusiasm, something that can have roots in paying a very large amount of money for a package and then getting done what you wanted to get done. That doesn't mean it's the best way to do something -- it just means this way works.
I've fallen off your lawn, and I can't get up.
What you describe is low-level GUI management, the kind of what is solved by following some GUI guidelines (like GNOME Human Interface Guidelines, for instance). It's certainly the kind of details that a programmer should know, but it is not enough to build a decent interface.
The core of a really good application is goal oriented software design (also called user oriented design). Before thinking about widgets and gadgets and frame layout, you should start by defining what the application must do and how to do it - and the key to this is to build a prototype and observing real users using it.
That's it, interface design must be an iterative process in which real user problems are observed in real use, and then fixing it with a new design for the real task that the user is trying to accomplish.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Before remaking their UI:s and such, please make them at least to _work_ together.
First, make them all handle the same file-formats - i.e. make them handle PNG and SVG. Not just pixmap formats, and not just a buggy SVG-model that can't handle fonts properly, but a fucking working import/export.
Secondly, make copy/paste of non-text data work. Implement something like OLE and make it work in _all_ apps.
An example of a scenario that does not work, but _must_ work: Start out to create a diagram in dia. Export to svg. Import i inkscape. Change some details. Save. Import in kpresenter or OO Impress.
For additional complexity, add some pixmap picture made in GIMP (with variable transparency) to the picture in Inkscape. Perheaps use eps in some steps instaed of svg. Also, you could import the vector-graphics picture as a path in GIMP somewhere in the middle too. Be sure to check that foints work all the way through, even with non-USASCII-characters (We non USAians don't like it when our Ås, Äs and Ös gets mangled to Ãås or =4711 or some other garbage).
When done with this, _then_ I think it would be apropriate to hack on the UI:s to get the a bit more streamlined. But until then, I'd much rather have it just work and look uggly, than not work bu t look great.
--The knowledge that you are an idiot, is what distinguishes you from one.
Also - don't pick a color scheme - let the system color it. .... Here in the States, Red means Stop, but this is not true in all cultures. Plus... some people are colorblind.
WARNING!!!! Format the hard drive???
[ Big RED Button ]
[ Big GREEN Button ]
Does RED mean cancel and GREEN mean go ahead?
Or does RED mean do the dangerous operation, and GREEN means safely skip doing it?
Red can mean stop or danger. Green can mean go or safety. In some cases, go = danger, and stop = safety.
Lesson: don't use color for primary communication. Use color only to enhance communication. Be careful of colors that might have different cultural or social meanings. Consider colors as something that must be translated just like the strings and prompts throughout the user interface.
I'll see your senator, and I'll raise you two judges.
When you know that you have libs-x,y,z, or need to include headers a.h, b.h, c.h, but where are they on your system?
I'm not a graphic artist by training, but 5 minutes after I downloaded GIMP I learned how to use it. Mind you, I'm far from being "competent" with the software, but the "stress" of the learning process is exaggerated. I mean, piano lesson is a bitch to a kid who's not too crazy about playing piano, but you cannot stop someone who has a passion for piano from sitting down at the old upright and practicing for hours. And I submit to you that learning how to use GIMP is easier than learning to play piano. This complaint about "UI problems" with GIMP, or "the lack of integration" issue, is missing the point: open-source software is for the passionate, the commercial-minded people should simply join the proprietary parade. Using GIMP and a free software called ArtRage, I made some graphics for my blog at: http://sunandfun.blogspot.com/ , if anyone's interested.
Sun and Fun
a port of Scribus to Gnome
Scribus already runs on GNOME:
Plus, why spend all of that time writing ports for 10,000 DEs and/or WMs, when you could spend that time improving the program itself?
make it able to address more than 2GB of RAM (it is my understanding that it currently can not, if this is incorrect, let me know)...hell, can it even so much as recognize that there is more than 2GB loaded into a machine and at least not subtract system overhead from 2GB to determine the max RAM available to it?... adobe's arrogance and lack of innovation is really starting to show when it comes to this...their refusal to make this happen and trying to blame it on hardware and/or OS limitations is reprehensible... i tried out gimp way back when and didnt care for it one bit...but if they could offer me a feature like this that would make my life and work easier i would revisit it in a second...
Instead of trying to get all these separate apps to agree on a single UI, script it.
Write the UI portion of the application in Python/Perl/whatever such that a user can drop in someone else's UI.
Clicking on a button would call into the C/C++ within the app to actually do the work. The scripting language would just layout the UI and respond to the user.
Then if someone wants a 'common' UI among the apps, they can make it themselves. No need to get the GIMP developers to agree with anyone else's UI philosophy.
I also personally find that holding the right button while painting is less precise than the left button.
The Farewell Tour II
I tried it last week.
1. I just still can't get over that lack of centralized window. I grew too used to a central window with PSP, Photoshop, Illustrator, and tons of other apps(MDI). I don't want an errant click accidentally clicking on a desktop icon. In Windows, I don't have multi-window desktop like on a typical X installation. Same goes for inkscape
2. (correct me if I get this wrong), multiple taskbar items. I would be happy with one, and the XP-style stacking is no substitute. Or is that just for inkscape?
3. Look at the screenshots. Are two file menus necessary? One for the image, and another for the tools? That to me seems like a waste of desktop real estate.
The screenshots with the super-huge menus/toolbars remind me of CNN, etc where they flood the screen with stock quotes, etc like on that SNL Skit("can we get a picture of the terminator robot up there?")
All of the screenshots have way too many big-ass dialogs, etc open. I want to see more of my image.
I tried to build Inkscape on several occasions. It took hours and hours because required libraries were not installed (or installed versions were too old for configure) on my (obsolete??) SuSE8.2 machine, and I still haven't been able to build the thing.
It's hard to help out if excessive dependencies hold me back.
Am I expecting too much for './configure; make; make install'? Anyone else run into this problem?
It can open photoshop, illustrator, and quark Xpress formats. You wouldn't [sic.] be surprised how many people use those formats...
I'd be surprised if more than a handful of people used them exclusively. Plus, this would only be an issue for designers who have libraries of 10,000 images that they're constantly modifying. For new artists with a small body of work, why do you need to interoperate with these proprietary files when you can start doing your work in OSS formats? It's like all of those people who say "I can't use OpenOffice because I have files saved in Word/WordPerfect format", when they only need to update their resume and shopping list every once in a while. Convert.
a little paintbrush is the standard paintbrush-type feature, not some random crap in one place and some other random crap in another place.
Again, in the case of GIMP, the paintbrush icon does just as you'd expect it to do. And GIMP would be the prime candidate for integration.
scan in a document, auto-level it, crop whitespace, and generate a thumbnail
Does the Adobe suite do this automatically for you? Does anything?
It sounds like you're not looking to switch to an OSS "suite" because you haven't fully examined the applications, or because you're looking for features that simply don't exist yet, in any software suite.
If you're a linux user, why don't you use WINE? Photoshop 6 (which is pretty nice) runs fine for me using it? It's a bit of a pain to install, since you have to modify your wine registry, and etc etc. I even got fonts and the eye candy filters working.
Alternately, you can go for the pay for play version CrossOver Office
Also, there's rumors of Adobe putting in Linux support for newer versions too
Cheezit! We're boned! - famous 31st Century bending unit
The real problem with OSS apps for graphic artists is that programmers do not understand how artists work. This has always been the dichotomy between programs with good GUIs and programs that don't. This is really part of the old Macintosh GUI guidelines, since all the really good graphic apps originated on the Mac and have the Mac's heritage of proper GUI development.
Apple and Mac developers have long relied upon what they call "Real-world metaphors." Early apps had to appeal to graphic artists with extensive experience in conventional methods, so the computer apps used tools that were metaphors for the real tools the artists alread used, tools like pencils, erasers, T-squares, dodging and burning photos, etc. Even more abstract tools like Photoshop layer modes are explained in the manuals by describing how layers of film would be sandwiched together, something every print designer would be intimately familiar with.
However, there has always been a legenary difference between Mac and Windows GUIs (and other GUIs that devolved from programmer's interfaces like X11), Mac interfaces work the way people really work with their jobs, Win/PC interfaces force the user to work the way the computer prefers you to interact with the job. This computer-centric approach will always fail when there is a user-centric approach available.
This is why the GIMP sucks and Photoshop doesn't. This is why Maya rules and Blender doesn't. There are almost no artists with sufficient skills to contribute code or GUI design, and almost no programmers with suffiicent knowledge of artistic methods to develop an interface that appeals to artists. If there were any crossover artist/programmers, they're probably already working with proprietary products and contributing to their development. Furthermore, many of the really good GUI ideas (i.e. the Maya Hotbox) are patented and not available to OSS.
Until OSS projects can focus on user-centric interfaces, and completely drop the programmer-centric geekery, they will continue to fail in the graphic arts market.
User interfaces for artists are, by definition, inconsistent. Are watercolors or acrylics a "better" interface for painiting? Will one produce a "truer" work with synthetic or natural modelling clays?
Warnock's Postscript was an amazing technical creation; I think it deserves its success over its page description competitors. Adobe also kept the Type 1 font hinting as their special technical secret about creating great fonts.
You'd expect Adobe's font creation tools, and vector graphic tools to monopolize their marketplaces. They don't.
Macromeida's Typographer dominates the "hinted font" market. And Corel Draw and Macromedia Freehand are solid competitors for Adobe's Illustrator almost solely distinguished by the look and feel of their user interfaces.
Page layout tools are a different area where Adobe has tried to buy its way into the market (Buying Aldus PageMaker) and use its weight to change the standards (PDF and FrameMaker). The suprise is that they haven't been more successful than they have been so far. While there are all sorts of legacy issues in this area, the extreme stinkiness of FrameMaker 1.0's user interface turned a lot of people off to their toolset.
And then the big suprise was the fantastic success of Adobe's Photoshop. There was nothing particularly spectactular technically about the bitmap files they were producing. But the amazing look and feel the Knolls' imbued in the user interface is what made this tool the success it was. The filter specs didn't offer anything much better than Pixel Paint or most other bitmap tools, but the sub-pixel look and feel of the tools gave Photoshop its anti-aliasing edge.
Personally, I think this standards war may already be too far lost. I'd look into something else. Suites of tools for school teachers or librarians. Something where there's a definite technical aspect, but where the personal touch can go a LONG way toward distinguishing and defining what people demand in their tools. I think artists may have already had these battles fought. While I'm not arguing about giving up, other areas might be more open toward wooing.
Anyone willing to fix GIMP2 or Inkscape in their current states into ready-to-go professional products will damned well have earned that $30.
Tech Public Policy stuff
I think there's a difference between learning to overlook idosyncrasities and learning an interface. In the case of a tool like GIMP, you already learned how to use the interface - Gnome or KDE in the common case. You then have to learn how to overlook the idiosyncratic way that GIMP works which is non-standard to each of those environments.
Yes, I myself agree that L hand on the keyboard, R hand on the mouse IS the right way of doing things (coming from electronics CAD background, not graphical arts background), but I was wondering recently: Why do not we provide UI emulation layers???
Remember in 80s/90s you could not get a decent DOS text editor which would not have switchable "Wordstar mode" or "Norton mode", and so on, making customers who come from your competitor make right at home. Yes, Emacs CAN emulate VI (see M-x viper-mode)!
It looks like now commercial SW vendors stopped that practice (I'm moving our CAD group from Mentor to Cadence and I'd REALLY like for Cadence to provide Mentor-like keybindings), but why can not GIMP can not give people a way to load "Photoshop Emulation" is beyond my understanding...
Paul B.
Unfortunatly Wine doesn't work for everyone. I've tried Paint Shop Pro 4,5 and 6 and can't get much of anything. Tried Photoshop (7 so I didn't expect much) and a few other problems. That's a funny thing about Wine - works fine with little problems for some, doesn't work at all for others =/
Do NOT click! This guy is trying it again.
If OSS applications where built to the Model-View-Controller pattern, than it would be easy to change all the OSS apps to have a unified look and feel. But instead of building the gui around the applications, applications are built around the gui.
Crashes after a few minutes. I didn't even do anything special. Just a little unsharp mask and levels.
When you use the GIMP it definitely changes your workflow. Then you get very used to it.
Big idea:
The right-click menu is exactly the same thing as the toolbar menu + picture-specific menu.
Which means you can do anything by right-clicking. What ends up happening is that you stop thinking about trying to "find" the file menu in the corner. Instead you just right-click whereever you are in your active image, and anything you do in that menu is applied TO that image (save, merge, filter, whatever).
I find to this be much less of a repetetious thing than having to shoot the mouse to the corner of the screen and navigate those menus.
Also, you will definitely want to dock all your options and stuff underneath your main toolbar (or create two, maybe put them on both sides of the screen). This is really, really helpful. Just open up ALL the dialogs but "windowshade" them in the toolboxes. This prevents any of them from unexpectedly showing up floating.
Unforuntaely in Windows, you can't tell it to remember to keep those one or two toolbars permanently on top and always in the same place. In Unix then you just take a picture, do maximize-available size, and presto, no overlapping windows.
I mean, the GIMP UI is really flexible. You'll want to make sure you set it up the way you like it, and keep it that way. It sucks that windows doesn't implement some features that it expects so that you can do things like freeze window locations, grouping windows together, or prevent them from overlapping and stuff.
But yeah, to re-iterate. 1) Right click means less moving mouse around 2) Customize your dialogs and toolboxes to keep things uncluttered.
3) Relies on window manager to keep dialogs and windows behaved (as this is the X11 way). Windows-port is working on MDI-like idioms to help out this problem
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Go back 5 years. Put Illustrator, Photoshop, Premiere, and Pagemaker side by side.
They all looked and behaved completely differently.
NOW they intergrate, look, and behave similarly. Sort of. And they "integrate" by copying features out of each other.
I wouldn't use the Adobe products as an example of how to make a consistant software suite.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Okay now, I'd already managed to figure out how to load a sequence of images/frames, but I've got some comments about it before I move to this weekend's stumbling block.
Okay, so it's got the usual drive/dir/file dialogs to select one image. Then, you have to go into another location to load any additional images. Annoying, but not a big deal, really. Now the interface for managing images is quite simple. You can just tell it how many frames (either forward or backward) from your reference frame you want to add. The problem, is that this entire procedure assumes that you know precisely which frames you want to load before you begin.
Well, you sure as hell don't want to use Cinepaint to browse through images. Sure, you can pull up the first frame in a sequence and then page to the next one, so on, until you find your starting and ending frames. But consider that it takes about two seconds to load each frame. If your starting point is one second into the clip, that's one minute of time wasted. The place in the sequence of frames that I wanted to edit just happened to be from frame 114 to 158. Since I already knew just how impractical it was to find this essential bit of info with Cinepaint, I pulled up a whole damn 'nother program (in this case ACDSEE) to decide which frames I needed. That's bad UI design. Period.
Now onto this weekend's nightmare. The Clone tool. I still haven't figured out how to use the damn thing. You can click on the Clone button and you can click on the image, but how the hell do you assign the selected area to a brush? Right click is no help and "Help" tells me all about the parameters of the Clone tool, but doesn't tell me how to use it!
I know it's gotta be something simple, yet also esoteric and non-intuitive. AKA, bad UI design.
But that's okay, it could be worse...
Blender. OMFG! A weekend playing around with that oh-so-aptly named program taught just how much I am willing to pay for a good UI. $790.00 That's the cost of upgrading my current version of Lightwave 3D to the newest and acquiring Napalm for the particle effects that I want to use on another project. It is simply not worth it to spend any more time fighting the UI to try to get something done.
Cinepaint has features that are unique and useful, which is why it is being used in production environments. Blender? Nope.
Mediocrity knows nothing higher than itself; but talent instantly recognizes genius. -- Sir Arthur Conan Doyle
And to comment on the "shift perspective"... it seems a lot of "creative" apps are going down this path when appropriate. Examples:
gimp - photo manip.
sodipodi - illustrator-like tool
dia - visio-like tool
gaim - IM/IRC client
All of them have the same document model, if you will. They employ a floating bar that while having a menu, largely is there in case you forget to right-click in an active area.
Same workflow ideas apply for all those tools and I feel it becomes re-inforcing.
That being said, many types of applications have no business using this model! For example, video/sound editors. (See Cooledit, Final Cut, Audacity and Kino as examples)... they've have got those UIs done right. Those applications are very "project" centric and thus should have a single window interface.
But I think the multiple doc+right click is really powerful when you are working on tasks where you often go back and forth between documents and it's very 2D-spatially oriented, you know?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Just start typing, and a text box appears.
If the file list is selected, then you'll get automatic completion/highlighting, too.
Or just hit '/' to get a more traditional window (still with automatic completion).
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
What I think we need is a fork. That will not save the imperoperabilties, but it will be a great application for Joe User. Since Joe Users now all have thier own digital camera, they want to do some stuff with their photos. Not "one-click-to-add-curly-frames-around-yer-pic", but simple things. Like rotate, resize, cut, crop, and some small colour/contrast changes. A fork of the gimp: The gimp light could be great for this.
Painter is the same way...the tools are in their own panel, and the painting is done in its own window. I don't really see a problem with this separation - it makes sense to me. The tool box is for tools, and the canvas is for drawing with those tools. It fits well with many real-life paradigms. Take a carpenter for example...does he take every one of his tools and lay them out on or around the object he's working on? Not really.
BTW - most tools in the Gimp are available in the canvas window - from the menus.
The problem I see isn't the necessarily the separation, but the workflow. The more I have to keep clicking different windows or selecting different tools just to do something that I should be able to do with my current tool, the more unncessarily cluttered the workflow becomes. I wouldn't mind seeing more attention focused on that particular aspect.
Actually, you're making a fairly wide-ranging and erroroneous generalization there. For example, one of the key people and admins for Inkscape is a professional artist, not programmer. Several other artists are also involved (including those with MFA's, etc). I myself am a programmer, but cut my teeth in charge of engineering for a small multimedia company, and even have formal art training. I can say with certainty that how artists work is well known and considered by most involved in the project (and man, some of those artists can be quite vocal).
The Gimp also has been fairly well used by art professionals. The Film Gimp (aka CinePaint) being one of the more intereting branches. That one is used by serious professional artists, and is worked on by many engineers who are paid to support those artists and give them what they need...
However, have you seen how they're taking their branch in regards to UI? They're switching it to FLTK. Personally I think it's one of the oooooogliest UI toolkits around (and very un-photoshop-ish). However, it is highly functional, and helping the artists get their work done is what the programmers at Rythm & Hues, Sony Imageworks, ILM, Dreamworks and such are paid to do. Trust me, they know art workflow.
Its the MacOS syndrome.
All the gimp folk need to do is slap all those tiny little windows into a master window (MDI)
and then I can avoid accidentally clicking on my desktop.
If they do that, GIMP is fucking perfect.