[Gimp-developer] A fresh pair of eyes.

2003-07-30 Thread Jay Cox
I first loaded up gimp 1.3.17 not long after my grocer and I split up. 
I had just gotten over a serious illness that I won't bother to talk
about, except that is had something to do with the miserably weary
split-up and my feeling that everything was dead.


This was the first chance I've had to spend quality time with gimp in
several years.  After this long separation from gimp, I feel that my
eyes are pretty fresh.  I hope my fresh perspective can spot some
problems that may be overlooked due to over-familiarity by those who
work on it every day, due to your over-familiarity.  Since it would take
far too long to write about all that is right with the new gimp I will
only write about what I find wrong with it.

Preferences-Interface-Tool Options-

Default threshold:  Why do we need this here?
Just remember the last value I set in each tool.
recommend removal

Default Interpolation:  Same as above.
The transform tools ignore this one anyway.
Perhaps we need to do something to make
the interpolation options stand out more
visually in the scale dialogs?
recommend removal


Brushes Pallet:

It won't let you delete those useless brushes that ship with the
gimp.  I know you can edit the brushes path in the preferences
dialog to get red of them, but most beginners will have no idea.
Unfortunately changing the brush path will remove all the brushes
even if there were a few you wanted to keep.  (This goes for
gradients and patterns also)

RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into
the users folder when it is launched for the first time.  Single
user systems will never miss the meg or two this takes. On
multiuser systems the admins can prune the system brush library.


The round brushes shipped with gimp should be editable.

RECOMMENDATION:  recreate the round brushes as .vbr brushes.


When previewing very large brushes the scaled down preview gets
wonky.

RECOMMENDATION:  Find and fix bug in code.

In the year 2003 why can't we scale pixmap brushes?

RECOMMENDATION:  Keep dreaming.

Making .gbr (or gih) type brushes is non intuitive.  It requires
saving as a .gbr file into a hidden directory (how many people
even know how to get into hidden directories in the gtk file
dialog?) and then hitting refresh in the brush dialog.  I just now
noticed script-fu-selection-to-brush.  Much better, but hard to
find.

RECOMMENDATION: Move aforementioned script-fu to the bottom the
   the main select menu. Do the same with to-pattern
   and to-image items?  (Should probably rewrite the
   script-fus as native functions) (should the main
   select menu be renamed to selection???)


When painting with large (400pixel+) soft .vbr type brushes
banding can be seen.

RECOMMENDATION: Do error diffusion dithering in brush mask
calculation?
   Double check the code vbr code for precision errors.
   The banding could be coming from somewhere else,
   make sure we don't just cover up deeper problems.
   (I'll track this one down myself)


When moving the mouse over an image window with a brush tool
selected, the brush shaped cursor outline seems to jiggle around a
little.

RECOMMENDATION:  Bow down and thank mitch for implementing the brush
shaped cursor feature.


Other Stuff

Leopard and Brick patterns do not properly tile.

RECOMMENDATION: get [EMAIL PROTECTED] to fix them.

It requires two key presses (shift and =/+) to zoom-in which is one
of the most common operations that gets used. (this is on US
keyboards)

RECOMMENDATION: accept '=' and '+' to zoom in.  Additionally setup
mouse
   button shortcuts for zooming in and out.  Perhaps
   ctrl-middle for zoom in, and ctrl-shift-middle for
   zoom out. This will keep peoples left hand on left
   side of the keyboard and their right hand on the mouse
   which is exactly where they belong. (is it a pita to
   have multiple keyboard shortcuts for the same item?)


Thats enough for now.  I'll add the important stuff in here to
bugzilla tomorrow.

Jay Cox
[EMAIL PROTECTED]

PS: I was skeptical at first, but I am happy with a 2.0 designation
for the next release of gimp.


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] A fresh pair of eyes.

2003-07-30 Thread Nathan Carl Summers
On 30 Jul 2003, Jay Cox wrote:

 This was the first chance I've had to spend quality time with gimp in
 several years.  After this long separation from gimp, I feel that my
 eyes are pretty fresh.

Whho!  I think I speak for all of us old fogies when I say,
Welcome back!

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] A fresh pair of eyes.

2003-07-30 Thread Alan Horkan

Welcome back.

On 30 Jul 2003, Jay Cox wrote:

 RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into
 the users folder when it is launched for the first time.  Single
 user systems will never miss the meg or two this takes. On
 multiuser systems the admins can prune the system brush library.

You have a point, I dont much like the proposed solution though.

 The round brushes shipped with gimp should be editable.

 RECOMMENDATION:  recreate the round brushes as .vbr brushes.

New file formats to be discussed at Gimp Con [1], but recreating the Round
brushes as standard brushes sounds good.

While we are on brushes I am wondering what kind of information needs to
be stored in a Brush file and why does it need a special file type of its
own?

 RECOMMENDATION: Move aforementioned script-fu to the bottom the
the main select menu. Do the same with to-pattern
  and to-image items?  (Should probably rewrite the
  script-fus as native functions) (should the main
  select menu be renamed to selection???)

Please dont.
The Select Menu is for making a selection, not manipulating the contents
of a selection.

Once you have made a selection then the contents of a selection is an
Object/Image/Layer and then actions get applied to it, the current image.

 It requires two key presses (shift and =/+) to zoom-in which is one
 of the most common operations that gets used. (this is on US
 keyboards)

 RECOMMENDATION: accept '=' and '+' to zoom in.

http://bugzilla.gnome.org/show_bug.cgi?id=94910
Both + and = should work, with + being the default label.
Anything else is just a nightmare for international users.

I would prefer if GIMP used Ctrl++ Zoom In and Ctrl+- as the default
labelled keybindings in the menus, as well as the above keybindings.

 Additionally setup
 mouse
button shortcuts for zooming in and out.  Perhaps
  ctrl-middle for zoom in, and ctrl-shift-middle for
  zoom out. This will keep peoples left hand on left
  side of the keyboard and their right hand on the mouse
  which is exactly where they belong. (is it a pita to
  have multiple keyboard shortcuts for the same item?)

I dont know about old Unix three button mice, I expect more users have
Wheel Mice instead so I really hope any changes you make wont adversly
affect them (and me).
Zooming with a Wheel Mouse should definately Ctrl+Wheel
(up  down == Zoom in  out) users already expect this from other
applications.
Wheel should scroll the page up and down, and Shift+Wheel should Scroll
sideways.

I know Paint Shop Pro uses the Middle Click of a Wheel Mouse to Zoom In
but I never considered trying to use it with a Shift/Ctrl modifier.

 Thats enough for now.  I'll add the important stuff in here to
 bugzilla tomorrow.

 PS: I was skeptical at first, but I am happy with a 2.0 designation
 for the next release of gimp.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

[1] Snowballs chance in hell I'll be able to afford to go to GIMP Con, I
only hope that people will take some notes and put up a short summary of
some of what gets discussed.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)

2003-07-30 Thread Tor Lillqvist
Tor Lillqvist writes:
  There also seems to be some handle leak when GIMP is starting up and
  queries all the plug-ins. Also, something needs to be done to #98737
  soon. (Perhaps related, I had to start GIMP at least four times before
  it got past all the plug-ins and wrote out the pluginrc file.)

Done:

2003-07-30  Tor Lillqvist  [EMAIL PROTECTED]

* app/plug-in/plug-in.c (plug_in_close): [Win32] Plug handle leak,
call CloseHandle().

and in GLib:

2003-07-31  Tor Lillqvist  [EMAIL PROTECTED]

* glib/gspawn-win32.c: When possible, manage without the helper
process. (Part of the enhancements outlined in #98737.) Speeds up
GIMP 1.3's first-time-run plug-in query phase a lot.

Plug a file descriptor (and thus Win32 handle) leak: close the
read end of the child error report pipe after use.

Now I can start GIMP 1.3.17 from fresh and it successfullly queries
all the plug-ins, quite fast even, with no handles leaked.

Still need to add script support to gspawn-win32.c so that Hans's
Python plug-ins work.

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer