[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [Gimp-developer] lgm 07, top?10 GIMP user requests...
From:       peter sikking <peter () mmiworks ! net>
Date:       2007-05-24 9:27:45
Message-ID: 05F1D135-3673-4175-B664-67C4F3F3D7AA () mmiworks ! net
[Download RAW message or body]

Saul wrote:

> Quoting peter sikking's weblog:
> (http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project- 
> overview.html)
>
> "ALSO NOT PAINTER
>      the focus for GIMP is to work with ‘found’ images;"
>
> I do not understand the reason for this restriction. Myself, I am not
> a painter. I do not use the GIMP for painting but I recognize that
> there are many who do.

"having a vision means saying no." --Steve Jobs

There is no obligation for GIMP to come to the rescue of every
pixel pusher under linux. And if there are enough desperate
painters out there who want really oil/water/finger paint in
GIMP, then they can get _their_ act together and have some
plugins written.

There is a long, hard road ahead of the GIMP team to get the
product vision implemented by core GIMP.

> It seems such a short stretch for the GIMP to
> extend its already powerful paintbox toolset to incorporate other
> painting concepts that I fail to see why development in this direction
> should not be encouraged.

If you going to support it, you have to support it well.

To give you an idea how this works out in user interaction terms,
imagine that for supporting natural painting, or website mock-ups
or page layout, an extra leg has to be sewn on the GIMP.

The GIMP will walk better and better, which each extra leg, no?

(sorry Sven, for using _the_ GIMP).

> On a similar note, I wish to express a related concern with another
> category of "user" who, in my opinion, is not being sufficiently
> addressed in the current focus on user interface design: the
> developer.

These are the makers of software.

This is the difference between the coolness of making movies,
compared to just going to the movies.

> In the Free Software universe, the most important users of
> software are the ones who contribute to the project; whether through
> documentation, language translation, meaningful bug reporting, or
> actual programming. It would seem that minimizing the demands on
> potential contributors should be a major focus of proposed changes in
> the GIMP's "user" interface

Then I would like you to tell me how to make life easier for my
fellow GIMP team members.

then Valerie wrote:

> Well, I'm among those who would like to use GIMP for painting, and  
> I have
> tried in the past. But having seen that blog recently, I can accept  
> that
> the developers would like to concentrate their efforts in a particular
> direction, so recently I've been looking to other open source programs
> such as Inkscape instead. They have limited resources as is, so you  
> can't
> blame them to want to do one thing Well, even if it means setting  
> aside
> others for now.
>
> I think the best alternative as a result would be to create a  
> separate,
> painting program, based on Gimp, but with more emphasis on painting
> options and less on filters and tools mostly used for photo  
> manipulation.
> Maybe it could incorporate Martin Renold's Mypaint and Levien's Wet  
> Dream
> for example.


> So an Open Source painting program would center around things  
> different
> than a photo manipulation program.


I could not agree more with Valerie. There is a 'marketplace' for
a painter-like application under linux. And also from a user
interaction perspective a new application would be much easier to
totally optimise for your painting user experience.

     --ps

         principal user interaction architect
         man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[prev in list] [next in list] [prev in thread] [next in thread]