Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-11 Thread Garry R. Osgood

Sven Neumann wrote:

   I don't see your problem. I do get my errors in the error-console. All
   that's missing IMO is a way to set the error_console as the default
   error_handler in the preferences. That should be easy and is definitely worth
   the effort.

  Nick Lamb:

  Well, I think you hit the nail right on the head, I have seen this nice
  Error Console dialog, and never found out how to get my errors reported
  there. From your description it sounds like that's just some plumbing.
 

  Sven:

 As said, I can't reproduce your problem here. As soon as I open the
 error_console, all errors produced with g_message () appear in that
 dialog instead of popping up a message window.


I also see this error console, but never see anything *in* the error console.
g_message() dribbles to dialog popups. Enlighten  me: what sort of
plumbing is involved? I've turned a couple of spigots, nothing comes out
of pipes.

Be good, be well.

Garry Osgood




Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-11 Thread Sven Neumann

  I don't see your problem. I do get my errors in the error-console. All
  that's missing IMO is a way to set the error_console as the default
  error_handler in the preferences. That should be easy and is definitely worth
  the effort.
 
 Well, I think you hit the nail right on the head, I have seen this nice
 Error Console dialog, and never found out how to get my errors reported
 there. From your description it sounds like that's just some plumbing.
 
As said, I can't reproduce your problem here. As soon as I open the 
error_console, all errors produced with g_message () appear in that 
dialog instead of popping up a message window.


Salut, Sven




Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-11 Thread Nick Lamb

On Tue, Jan 11, 2000 at 11:50:28AM +0100, Sven Neumann wrote:

 As said, I can't reproduce your problem here. As soon as I open the 
 error_console, all errors produced with g_message () appear in that 
 dialog instead of popping up a message window.

Oh, I see. Somehow I expected that all my errors would appear in that
box, regardless of whether they happened before it was visible. Having
played with that part I see what you mean... 

I'm still not sure quite what I wanted this to do, but it does *do*
something useful so strike that from the Triage list.

Nick.



Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-11 Thread Raphael Quinet

On Tue, 11 Jan 2000, Nick Lamb [EMAIL PROTECTED] wrote:
 On Tue, Jan 11, 2000 at 11:50:28AM +0100, Sven Neumann wrote:
  As said, I can't reproduce your problem here. As soon as I open the 
  error_console, all errors produced with g_message () appear in that 
  dialog instead of popping up a message window.
 
 Oh, I see. Somehow I expected that all my errors would appear in that
 box, regardless of whether they happened before it was visible. Having
 played with that part I see what you mean... 

So maybe what we need is a new option in the gimprc, something like:
  make-error-console-visible-on-first-g-message-and-leave-it-open
If you set that to true, then the error console would do what you were
expecting.  Or did I misunderstand this discussion?

Now if only all errors, debug messages and so on could use g_message()
instead of printf() (in some plug-ins), then everything would be
perfect...

-Raphael



Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-11 Thread Nick Lamb

On Tue, Jan 11, 2000 at 06:15:11PM +0100, Raphael Quinet wrote:
 So maybe what we need is a new option in the gimprc, something like:
   make-error-console-visible-on-first-g-message-and-leave-it-open
 If you set that to true, then the error console would do what you were
 expecting.  Or did I misunderstand this discussion?
 
 Now if only all errors, debug messages and so on could use g_message()
 instead of printf() (in some plug-ins), then everything would be
 perfect...

Mmmm, well that was part of my sort of half-thought-through expectations,
we should see a lot MORE messages in a thing like the Error Console
because we don't have to click "OK" for every single message...

e.g. In the PNG plug-in, if I knew I was talking to the console, I
would feel happy to report blow-by-blow CRC errors which may occur
a few dozen times in a single (corrupted) file. However as a user I
don't want twelve OK buttons to hit if I haven't got the console :)

As it is, some PNG errors are reported to stderr, which is probably
not useful to anyone (but it's default libpng behaviour so I have
never gotten around to turning it off) and all fatal errors are
reported via one or two general purpose g_message-type calls.

Nick.



Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-10 Thread Garry R. Osgood

Simon Budig wrote:

 Sven Neumann ([EMAIL PROTECTED]) wrote:
   How about some comments for feature triage? There are some features in
   Gimp 1.1.x which are buggy or unusable, yet stay the same for weeks

 snip...

 Ill try to do something on the tool in the next time, but as always I
 cannot promise anything. The first thing would be the API cleanup, the
 second thing would be to prepare the conversion to a selection, but bound to
 some strange events, since we need the Integration for the right way to
 do it.

If there were one feature of Simon's path tool that I would like to have
automagically appear in the Integrated path selection tool, it is the ability
to manipulate the curve by "pulling" on it directly. it is a very pleasant
way to adjust curves. It's effect needs to be adjusted near control points;
bezier basis functions associated with the first and fourth control points
grow expotentially to unity, so manipulating Simon's path near control
points can be a tad exasperating.

Be good, be well

Garry




Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-10 Thread Simon Budig

Garry R. Osgood ([EMAIL PROTECTED]) wrote:
 If there were one feature of Simon's path tool that I would like to have
 automagically appear in the Integrated path selection tool, it is the ability
 to manipulate the curve by "pulling" on it directly. it is a very pleasant
 way to adjust curves. It's effect needs to be adjusted near control points;
 bezier basis functions associated with the first and fourth control points
 grow expotentially to unity, so manipulating Simon's path near control
^  infinity?
 points can be a tad exasperating.

Yeah. The basic idea is, that when you drag on the curve near an endpoint
you dont want to change the curve at the other endpoint. So I have to
move the handle from the near endpoint more drastically to achieve
the "curve-dragging" effect. Maybe I should limit the ratio at some point...

Anyway: It is not too hard to get the control-point back: Simply drag
the curve near the anchor towards the anchor. The controlpoint will
appear as quick as he went away earlier :-)

Bye,
Simon
-- 
  [EMAIL PROTECTED]   http://www.home.unix-ag.org/simon/



Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-10 Thread Nick Lamb

On Mon, Jan 10, 2000 at 10:29:29AM +0100, Sven Neumann wrote:
 Oops, I thought (but should have checked) that image_set_resolution_invoker 
 was calling the gimp_image_set_resolution() in app/gimpimage.c. And probably
 it should since the core function keeps the undo_stack in sync by calling
 undo_push_resolution (gimage). On the other hand if called from the PDB, we
 probably don't want to gdisplays_shrink_wrap (gimage)...

Um, yes, that's pretty much the sequence of thoughts that went through
my mind. However, doing a good job of removing such redundancy will
take a lot of time, and provide no noticeable improvements (save the
possibility of stumbling on a bug fix) for our poor users.

--

It's the start of a new year, and my mind turns to Spring cleaning already

How about some comments for feature triage? There are some features in
Gimp 1.1.x which are buggy or unusable, yet stay the same for weeks
at a time. Without paid staff to do this work, we must throw away [*]
stuff that's not going to make it. On my short list...

* Resizable toolbar
* Natural airbrush
* Error Console (well, here it is, but where are my errors?)
* Display Filters
* Paths

More? Comments from people who started these features? This is your
excuse to tell us the long tale of how the perfect 100% bug free
version of Fill-in-your-feature was tragically lost to a Volcano
during your desperate struggle to save an innocent baby...

Nick.

[*] Well, put it to one side until 1.3.x, but even then, if no-one
will write code for it, how will the feature get finished?



Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)

2000-01-10 Thread Simon Budig

Sven Neumann ([EMAIL PROTECTED]) wrote:
  How about some comments for feature triage? There are some features in
  Gimp 1.1.x which are buggy or unusable, yet stay the same for weeks
  at a time. Without paid staff to do this work, we must throw away [*]
  stuff that's not going to make it. On my short list...

[...]

  * Paths
 
 Simon ?

Umm - Yes. I´m terribly sorry, but at the moment my Dis-organizer works
a little bit too well. A short summary of the state of the tool:

Good News:
* Manipulating the path works, maybe needs some minor cleanups.
* Converting to a selection probably is easy, since there is code
  from Andy to convert an array of floats to an selection.
* The code seems fairly stable - I dont get crashes at the moment.

Bad News:
* The API for new path types is not sane at the moment. At some points
  are Ints instead of floats, some functions do have too much parameters
  and so on. 
* The integration with the paths Tab in the LC Dialog/the PDB Path API/
  The XCF-Format is probably horrible - at least for me. Im not sure
  if this is on the TODO for 1.2, since there are lots of points, where
  we can break something.

My point of view: If the Integration of the Paths tool could not be done
before 1.2 we should not include the tool. Its use is too limited in the
current state. It should be fairly easy to remove the files shortly before
the 1.2 release if necessary.

Ill try to do something on the tool in the next time, but as always I
cannot promise anything. The first thing would be the API cleanup, the
second thing would be to prepare the conversion to a selection, but bound to
some strange events, since we need the Integration for the right way to
do it.

Hope this clears some things. Ill respond to questions... :-)

Bye,
Simon

-- 
  [EMAIL PROTECTED]   http://www.home.unix-ag.org/simon/