Re: [Gimp-developer] Tool statusbar error messages

2006-10-02 Thread Carol Spears
On Sun, Oct 01, 2006 at 12:04:47PM -0400, Christopher Curtis wrote:
 I hope I'm not showing my lack of UI skills here, but:
 
 On 9/26/06, Carol Spears [EMAIL PROTECTED] wrote:
 On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote:
  Indexed images are not currently supported.(heal)
  Healing does not operate on indexed layers
 Healing cannot manipulate indexed images.
 
 Cannot heal indexed images.  Use Image-Mode to change color mode.
 
 Points:  Instructs how to fix the problem.  Concise enough (I hope) to
 fit translations.  Remove Use if constraints prevent users from
 seeing Image-Mode (the important part) when clipping.
 
i think that your rewrite is very good.

it actually causes me to wonder what has happened to humans that we need
to have these messages all over the place though.  could it be that so
many of the 'needs' of users has been fabricated? (fabricated here
meaning invented in such a way to make it seem as if there is so much
unhappiness and so that it allows something that was really really good
to be changed to be not so good)

 And as a general, pie-in-the-sky, comment:
 
 It seems that indexed mode editing is cumbersome, confusing, and
 limited.  When core operations are moved into a GEGL, The GIMP should
 probably lose indexed mode editing (indexed formats autoconvert
 to/from) and a separate tool be created just for this type of editing.
 
 More blue sky:
 
 It would be really slick if all GEGL-apps could shuffle images amongst
 themselves, assuming that interface is intuitive.  So that, for
 example, an indexed editor, a pixel editor, a SVG editor, and a
 prepress app could all have a 'window' onto a shared image stored in
 GEGL space.
 
indexing images is used only because a good and free animation format
has not been agreed upon or for games or simple graphics for speedy web
pages.

perhaps the need to continue to clutter gimp gui is more a failure of
all of the communities who are supposedly there adding to the wealth of
information that is already known about image manipulation and also
about working with GIMP specifically to make images.

how many different ways does the same thing need to be said?

could (perhaps) everyone take a step back and a few minutes to consider
that it is actually not possible to make an application that is as
strong as GIMP that will work easily for people who will not take the
time to become familar with it and get on with something that is more
productive.

i will be honest.  i do not think that i will ever see that message in
the status bar before i will see it in my own mind based on my
experience(s).

restated.  where are we going?  will we want to be there once we arrive?

carol

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


Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)

2006-10-02 Thread Sven Neumann
Hi,

On Sun, 2006-10-01 at 07:23 -0700, Saul Goode wrote:

 To a large extent, all operations in the Layers menu do not honor
 selections. The notable exceptions are:
 
 Transparency-Color To Alpha
 Transparency-Semi-flatten
 Transparency-Threshold Alpha
 Transform-Arbitrary Rotate

These are plug-ins (color2alpha, semiflatten, threshold_alpha) or tools
(Rotate tool). Plug-ins automatically honor the selection, they can't
modify unselected pixels, Arbitrary Rotation is just a shortcut for
switching to the Rotate tool.

 5) Restore the option to use the space bar to move the current layer
 without any dialog being presented. This could readily be implemented by
 executing the Move Tool in the ignore selection mode.

The space bar feature is still present (as an option) and it has always
been implemented by switching to the Move tool temporarily.


Sven


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


Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)

2006-10-02 Thread Saul Goode
  The space bar feature is still present (as an option) and it has always
 been implemented by switching to the Move tool temporarily.
 
 
 Sven

Indeed, you are correct. I must have switched the affect: option of
the Move tool during my experimentation and failed to restore it.

 These are plug-ins (color2alpha, semiflatten, threshold_alpha) or tools
 (Rotate tool). Plug-ins automatically honor the selection, 

And being able to make such a blanket statement should simplify things
for the user. Unfortunately, without a way of differentiating between a
plug-in or a core function in the menu system that knowledge is of no
benefit to the user.

Nonetheless, of more importance than the Layer menu, it would be of
great benefit to the user interface to be able to make such a general
statement about tools (i.e., tools automatically honor the selection).
Since there is only one tool that violates this at the current time, it
would seem most reasonable to make that tool conform; especially since
Move operations bear such a connection and similarity to Transform
operations.

The current Affect: options of the Move Tool and all of the transform
tools have the same tool hints: Transform Layer, Transform
Selection, and Transform Path. There is nothing in the user interface
to suggest that the Move Tool does not honor selections while the other
tools do. It seems to me that adding a Transform Selection Contents
mode to the Move tool and a Transform Layer mode to the transform
tools would provide an extremely desirable commonality while correcting
an obvious inconsistency.


It is amazing what you can accomplish if you do 
not care who gets the credit. -- Harry S. Truman


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


Re: [Gimp-developer] Tool statusbar error messages

2006-10-02 Thread Kevin Cozens

mitch wrote:

I just comitted a change that moves all tool error messages that
can happen when clicking the image to the image window's statusbar,
using the new gimp_statusbar_push_temp() API.


I will have to see how this works in practice. I have some doubts as to 
whether this is a good idea. For myself I'm not that used to looking at the 
statusbar for tool related messages. I would be concerned whether important 
messages might be missed if they are only in the status bar. It would also 
take longer to read messages in the statusbar when the image windows is not 
wide enough to display the entire message at once. You would have to wait for 
the message to scroll through the statusbar in order to read all of it compare 
to seeing it all at once if was in a pop up dialog box.


--
Cheers!

Kevin.

http://www.interlog.com/~kcozens/ |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 disclaimer/favourite   |  -Pinkutus  the Borg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


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