Re: [Gimp-developer] rectangle tools

2005-02-25 Thread Raphaël Quinet
On Thu, 24 Feb 2005 10:23:08 -0800, "William Skaggs" <[EMAIL PROTECTED]> wrote:
> A) Use a dialog similar in general appearance to the Crop Tool dialog,
> and allow the user either by checking a Tool Option or by pressing a
> modifier key to enable/disable showing the dialog.  Of course the
> actual contents of the dialog are subject to improvement.
> 
> B) Use the Tool Options as the place where information is entered, and
> don't have a dialog at all.
> 
> It is of course possible that there are other approaches that haven't
> occurred to me.

Here is one that you haven't mentioned:

C) Use the status bar for displaying and modifying the position and
   size of the selection.

Instead of displaying a simple text label with the size of the
selected area, the status bar could automatically replace this text by
two (width, height) or four (x, y, width, height) entry boxes when the
user starts selecting something.  The value in these boxes would
change while the user is dragging the rectangle and modifying the
selection interactively but it would also be possible to edit the
values directly in the status bar.

Note that these entry boxes would only need to be there while a
selection is being modified (i.e., after the first click and drag).
They do not have to be there all the time while a selection tool is
active, so the status bar can still be used to display some other
useful information as text when the user is not currently editing a
selection.  This also means that the box and drop-down list with the
zoom ratios can be temporarily replaced in order to gain more space
in the status bar for these new entry boxes.

In addition, a small icon or expander button could be added to the
status bar while such a tool is in use; clicking it would pop up a
dialog box containing more options.  There are always more options
that could fit in the status bar, such as constraining the selection
to a fixed aspect ratio, etc.  A little button in a corner of the
status bar would provide a convenient way to display this dialog with
advanced options only when needed.

> Personally, of the two, I favor A, for a couple of reasons.  

If C is not accepted, then I favor B.  Although you are right that the
Tool Options were not intended to be used for active control of a
tool, I think that the disadvantages of having a window that gets in
the way outweight its advantages.  By the way, the status bar is part
of the image window so unlike the additional dialog or even the Tool
Options, it will never get in the way of the interactive selection.

I think that option C would be the most user-friendly: the important
information is visible without getting in the way, the interface is
easy to understand, and there is no need to remember special key
combinations for showing/hiding the dialog with extra options.  The
disadvantages of option C are that it would require more coding due to
the modifications of the status bar and it would not be possible to
display all entry boxes if the image window is too narrow.  On the
other hand, it would be easy for the user to make the window wider
whenever necessary.

-Raphaël

P.S.: I hope to see some of you at FOSDEM on Saturday and Sunday in
  Brussels.  As I already mentioned on IRC in #gimp, I'll try to
  offer some good Belgian beers to any GIMPers who come and say
  hello.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: Rect tool

2005-02-25 Thread danni
Can I propose 2 more options

1) Pop up dialogue is activated by hotkey (and perhaps on screen widget) - 
this approach is used quite successfully in several 3D applications. Usual Tab 
or N "numeric" is used.

2) Draw options on canvas - perhaps with hotkey/widget to show hide these 
additional options This has the additional advantage of not obscuring the 
picture while adding numerical input. 

I can do some mockups if that makes any of this clearer.

-- 
Oh, get ahold of yourself.  Nobody's proposing that we parse English.
 -- Larry Wall in <[EMAIL PROTECTED]>
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP and multiple processors

2005-02-25 Thread Jay Cox
On Wed, 2005-02-16 at 22:42 +0100, Sven Neumann wrote:
> Hi,
> 
> I couldn't resist and changed the PixelProcessor to use a thread pool.
> Main motivation was to make progress callback work for the threaded
> case. So there's now a variant of pixel_regions_process_parallel()
> that takes progress function and data. This allows us to parallelize
> some of the slower core functions (like for example gradient blend).
> 
> It would be interesting to know if this actually gives a noticeable
> speedup on SMP systems. Would be nice if one of you could give this
> some testing. Please try to do gradient blends (w/o adaptive
> supersampling!) on large images. Changing the number of processors in
> the preferences dialog allows you to switch between using the thread
> pool and the single-threaded code.

Here are some results for you:

Dual 2.5ghz g5 mac, mac os x 10.3.8
CVS gimp Changelog revision 1.10539

Linear Gradient blend on a 3000x3000 pixel image (Dithering on)
1 Processor:   7.98 seconds1x
2 processors:  5.20 seconds1.5x
3 processors:  5.23 seconds1.5x

Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF)
1 processor:   3.89 seconds1x
2 processors:  2.37 seconds1.7x
3 processors   2.40 seconds1.7x

Clearly the gradient code could use some tuning.  A linear blend
shouldn't take much more than 1/2 a second even with dithering.

The reason why the dithering case gets less of a speedup is because the
threads are fighting over the GRand state.  Each thread needs to have
it's own GRand state.

It looks like the threads are also fighting over gradient->last_visited.
My guess is that fixing this will get us much closer to the ideal 2x
speed up.

I don't see myself hacking on the gradient code in the near future so
anyone else should feel free...

Jay Cox
[EMAIL PROTECTED]


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] choosing default file open handler with multiple handlers

2005-02-25 Thread Pepster
Answering myself, just in case someone in the future needs the answer.
Plugins are sorted alphabetically by "label" (7'th argument to 
gimp_install_procedure), which is the same as "File Type" (i.e. the name you see 
when you open the "Select File Type" expander in the open image dialog.
So, you can select the default by selecting the appropriate label for each plugin.

-Joseph
Pepster wrote:
Hi,
When there are several plugins registering handlers for the same file 
extension, what/who exactly determines who ends up as the default handler?

(I want to be able to force my own preference as to what is the default, 
without success so far. Tried changing the plugins names, their order in 
pluginrc - all to no avail)

I tried looking at the code but it's not obvious ...
Thanks, Joseph
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] rectangle tools

2005-02-25 Thread [EMAIL PROTECTED]

]> A) Use a dialog ...

Dialog boxes that get in the way are annoying (like popup ads).


]> B) Use the Tool Options ...

Good choice. People already look there for similar control.


]C) Use the status bar...(x, y, width, height) entry boxes...
]...A little button in a corner of the status bar ...

Tool Options would be more consistent than the status bar, 
as is evidenced by the type of work required to modify 
the status bar.  Most arguments for C are also arguments for B.


D) If you want a button like option C to activate a dialog, 
it could go in the Tool Options instead of the status bar.

This is preferable to A and C, but I prefer B over all.  
If you must hide some options you can make them collapsable, 
but I advise against having these options collapsed by default.


I vote for B, D, C (in that order).

_-T


___
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer