gimp-developer-bounces@xxxxxxxxxxxxxxxxxxxxxx wrote: > Hi all ! > > > This is a long post, replying to many previous posts, and adding some parts > from IRC chats, and some even from discussions with Gimp developers. > ... > I have a degree of sympathy with this post although it seems to go to the other extreme. Backwards compatibility *is* overrated. Autotools is a great example of what happens if you don't trim the crud out of your software. No doubt, I can compile Gimp on every Unix platform ever conceived between now and 1972 but I still have to learn about 4 different languages before I can begin to start understanding how it works, let alone deciphering the scripts. Call me an idiot if you like, but it shouldn't be easier to learn the finer points of C++ than the tool that simply builds it. On the other hand, we have KDE 4. Plenty of improvements, no doubt, but no users left to appreciate them. :) As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more. Luckily for me, canvas right-click still provides the feature. I needed it, btw, because I wanted to add several guides to my project, one after the other. Rather than having to navigate all the way to that menu item every time, it's much easier to just have it available on the screen. That's not the only use of this feature, btw. Another good use is for learning keyboard shortcuts. No need to hover the mouse over an icon for half a second; just glance at the menu. Like I said, I don't know what's happened to this (really nice) feature but I did find a clue in some Java/GTK SDK documentation which states that usability studies have concluded that menu tear-offs are a bad idea and should be avoided. Oh dear, I thought. Someone's been conducting usability studies. Not that I have anything particularly against UI studies, but the method had better be sound, the assumptions had better be correct, and the results had better be applied appropriately. If the conclusion comes as a surprise, re-examine the experiment...carefully. Anyway, getting back to the Gimp, I'd be willing to bet real money that whatever ideas you have about a typical Gimp user are probably wrong. By all means, design for whatever you think the common use case is likely to be but remember that Gimp is (to borrow a programming term) a low-level IMP. That makes it even more likely that usage patterns from one user to the next will be radically different. If you don't enable Gimp's users to do the things that you can't think of, you'll just have non-plussed Gimpers. If you take away those things? Well, good luck with all the hate. :) ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)--- _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
