Re: [Gimp-developer] Negative Press
I suspect the true "problem" isn't one about the process, but one about the perceived results. When you think about it, people rarely criticize a project Just for the process. People criticize MS Windows for being closed-source and thus full of bugs and functionality problems, but nobody criticizes Apple, which is More closed-source in many aspects, because it actually does a good job. Basically, even though people do not realize it, their reaction may actually be something of the following: - GUI team: We can handle the work just fine right now, so we don't need extra people in our team. - Others: (Yeah? Then why's the interface still so bad?) I say this because after an amount of introspection, I realize that I might have been guilty of this. I short, I suspect that people are unconsciously blaming GIMP's Current GUI shortcomings on the GUI team, even though it's not their fault because: - they actually haven't had the opportunity to show what they're fully capable of - and many GUI problems are actually due to internal architecture limitations (layer groups, brush folders etc) This unconscious connection between the current GUI and the GUI team's possible accomplishments may give the impression that the GUI team is under-qualified or incapable of handling the job by themselves, which is why outsiders snipe at their reluctance to let others join their team in a more permanent way. At the base of the issue, there may be a transparency problem. Basically, there is no easy way of tracking the works of the GUI team right now. There are only three ways of seeing what exactly what they're up to: - reading the ideas they've come up with thanks to the GUI blog submissions (which are only made up of a few lines, aren't that easy to find back, and are relatively rare) - go to gui.gimp.org , click "User evaluation notes," then click "Notes" for individual scenarios, then be confronted with a wall of text on technical evaluations that most users don't want to bother reading. - go to gui.gimp.org, go to "UI specifications," and find... a total of 1 entry, for 2.4. Given this lack of easy, visible and regular updates, people "conclude" that little work is being done. The easiest solution, as far as I can tell, is actually to apply the same principle that the GIMP site's "Feature" page and that the GIMP UI brainstorm blog apply themselves: using pictures to speak a thousand words. The summary would basically roughly serve the same purpose as a visible 2.6 milestone (which should also have mock-ups) would from a PR point-of-view: show people what's in planning so that people won't think of GIMP as a dead project that isn't moving anywhere. Inkscape has a screenshots section for future features, and that does wonders for showing people the future evolution of the program. Are there any plans for a "Future feature" page on the GIMP website? If there is, it could be made up of two sections: - Future features (with mock-ups based on the 2.6 milestone) - Future GUI improvements (a whole section dedicated to GUI improvement! This is sure to score points among critics of the GIMP interface) The future GUI improvement section could contain screenshots of a few key UI improvements in planning (they don't need to include everything), with eventually an explanation of dependencies such as GEGL. As long as people know that they Are being planned, they'll be relatively happy and not get the impression that GIMP doesn't care about UI improvements. If the features aren't planned for any time soon but Are on the long-term plans, an explanation is enough to let users know that the GUI team isn't GUI-stupid but simply isn't capable of implementing the changes Yet. Then add a call for help on implementing prior dependencies, and maybe you'll even get more developers. Said section could end with "Got more ideas? Submit to the GUI-brainstorm!" And that's it. PR problem solved. Lack manpower? Get someone else to do the mock-ups for you. Given the number of submissions to GUI-brainstorm, it should be easy enough to find someone. Add the occasional news update on GUI rework progress, and that's even better! "GIMP is finally taking the GUI problem seriously!" - would claim people who haven't noticed the work already under way. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
> > Contrast the GIMP UI redesign with the GIMP project as a whole, which > invites and receives patches, bug reports, and ideas from scores of > outsiders. > The focus was on the UI redesign, not GIMP. In fact the quote above compliments GIMP (but at the UI redesign's expense). -- Tim Jedlicka, Network Entomologist [EMAIL PROTECTED], http://www.galifree.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Date: Sat, 3 Nov 2007 14:47:18 -0400 From: "Barry Loo" <[EMAIL PROTECTED]> GIMP just got some negative press at linux.com. What are y'alls opinions on it? http://www.linux.com/feature/120635 I've had my share of issues with the GIMP UI (and I've been vocal about it at times), but I think this piece is completely off the mark. It's really no different from a group of people going off into a small room to focus on something rather than being constantly interrupted by everyone passing by. That was a particularly unfortunate out of context quote of Peter Sikking's. The only one of the three that I've met is Ellen Reitmayr (at the April 2006 printing summit in Atlanta), and my impression was most certainly not that she isn't interested in listening to other people. She and a couple of other of the UI folks spent a couple of hours brainstorming on Gutenprint UI issues. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Barry Loo wrote: > GIMP just got some negative press at linux.com. What are y'alls opinions on > it? > > http://www.linux.com/feature/120635 As far as GIMP is concerned, http://www.linux.com/?module=comments&func=display&cid=1169329 and http://www.linux.com/?module=comments&func=display&cid=1169345 are the appropriate answers. And I do suspect that the icon problem isn't as serious as the author wants it to be, either. Nathan has obviously been bribed by a closed source company to disrupt the open source community. Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
On 11/3/07, Barry Loo wrote: > GIMP just got some negative press at linux.com. What are y'alls opinions on > it? > > http://www.linux.com/feature/120635 This is quite unusual for Nathan to miss the point *that* much. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Negative Press
GIMP just got some negative press at linux.com. What are y'alls opinions on it? http://www.linux.com/feature/120635 Loo ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP 2.6 and Script-Fu
Greetings. The Script-Fu plug-in in GIMP 2.4 uses version 1.38 of TinyScheme. There are about 8 bug fixes to that version of TinyScheme listed in SourceForge. Most of these fixes have not been applied to the TinyScheme used in Script-Fu. I would like to apply most, if not all, of these fixes to the TinyScheme used in GIMP. A couple of the bugs may have already been fixed but differently to the official version of TinyScheme. One of the bugs fixed in GIMP's TinyScheme may have a better fix in the official version although this needs to be verified. The first step would be to create bug reports for each needed plus a tracking bug. Not all of the outstanding bugs need to be included in TinyScheme. Some bug fixes could be held off until after post 2.6. The bug fixes can be applied quickly so there is plenty of time to run any needed tests on the fixes before 2.6 is out. It would also be nice to see support for radio buttons added to Script-Fu. I might need to consult on this with someone as I'm not that good at GTK programming. I almost had it the last time I tried a patch for this but I didn't get it 100%. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] momentary shortcut to the zoom tool?
There doesn't seem to be a way to temporarily switch to the zoom tool while a button is pressed. For example if I hold down ctrl + space, it would switch to the zoom tool, I could click-drag a rectangle to zoom, and let up on the ctrl + space, and it would switch back to the tool that was selected previously. I used this in photoshop all the time, so I can attest to its benefit. I realize there are shortcuts in the GIMP for zooming. The scroll wheel comes to mind, but zooming by dragging a rectangle is often much more useful for zooming in, and switching to the zoom tool by going over to the toolbox, clicking the zoom tool, then going back to draw the rectangle, then going back to the toolbox to re-select the previous tool, then back to the image to do the thing you were going to do... And I also realize there's a shortcut key for the zoom tool, but even then you have to switch back to the previous tool, which often requires a more difficult shortcut key than Z and probably a good memory too (there are over 30 different tools after all.) Another conceivable solution is simply to have a way to select the previous tool with an easy, left-handed shortcut. Doing that wouldn't be quite as simple for zooming as the momentary zoom idea, but on other occasions might be useful in its own right. What do you all think? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
> Currently, GIMP tries to do a bit of both in the same jpeg plug-in and > does not do either of them correctly: Raphael: These subjects were discussed before in the list when I ranted about almost the same. Since that some changes were made in the jpeg plug-in for GIMP 2.4.0 and imo they covered the real issues very well (now the plugin uses the existing quality instead of hopelessly destroying the original file changing its quality to 85). Anyway, I agree that the default quality for new images (85) is kinda low. Something between 90/93 should be better for the default value. The plugin already offers the possibility to change that setting in the first save (and better, the plugin lets you set a new default clicking a single button). So it's not a big deal. Another aspect I would suggest to change is the default subsampling. 1x1,1x1,1x1 (the best quality) is imo the better choice, because it gives a larger file, but much better quality. As this setting is hide under the "advanced options" tag, for the regular user it would be better if the best quality is provided, instead of the the best compression. Best compressions is an optimization. If you need a smaller file, it's a nice option. But regular users (user case: Jane wants to make minor adjustments of brightness and contrast images and remove red eyes on her birthday party) will expect the best quality by default. That's why I think the default values should be changed. About the rest of the current plugin interface, it looks just fine for me. You just mentioned PS. They chose these settings by default (higher quality and better subsampling). People (like myself the first time) tend to believe that PS offers better quality because of that. That's not true and simply changing the default values should help to destroy that false claiming. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer