Re: [Gimp-developer] Negative Press

2007-11-03 Thread Valerie VK
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

2007-11-03 Thread Tim Jedlicka
>
> 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

2007-11-03 Thread Robert Krawitz
   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

2007-11-03 Thread Michael Schumacher
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

2007-11-03 Thread Alexandre Prokoudine
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

2007-11-03 Thread Barry Loo
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

2007-11-03 Thread Kevin Cozens
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?

2007-11-03 Thread Daniel Falk
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

2007-11-03 Thread Guillermo Espertino

> 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