Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
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)
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)
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)
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)
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)
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)
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)
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: [gimpwin-users] PNG blank display bug
Hi, I have changed the core so that it does not accept zero resolutions. Additionally I have changed all plug-ins that try to set the resolution to check the value and simply don't set it at all if it is invalid. Gimp will then use the default set up by the user. Perl, IIRC teaches us that "There's always more than one way to do it", while it seems that Gimp teaches us that "There's always more than one place to change it." If we do not accept arbitrary values for xresolution yresolution we need to check for this in image_set_resolution_invoker as well. This is the approach I've taken in current CVS. Alternatively we could change image_set_resolution_invoker() and similar functions to be thin wrappers around core functionality -- I do not have time to do that, but perhaps someone else does? 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)... Salut, Sven
Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
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/
[gimpwin-users] PNG blank display bug
Matt.Wilkie writes: I'm getting this weird display problem with some PNG images, a sample is attached. Please let me know if you do/don't have similar problems. The PNG apparently claims to have the display (and print) resolution of 0 pixels/inch... Set it with ImageScale ImagePrint Size Display UnitResolution X and Y and the image appears. The PNG plug-in probably should check for this and use some sensible default if the file claims 0 dpi? --tml
Re: [gimpwin-users] PNG blank display bug
Matt.Wilkie writes: I'm getting this weird display problem with some PNG images, a sample is attached. Please let me know if you do/don't have similar problems. The PNG apparently claims to have the display (and print) resolution of 0 pixels/inch... Set it with ImageScale ImagePrint Size Display UnitResolution X and Y and the image appears. The PNG plug-in probably should check for this and use some sensible default if the file claims 0 dpi? I have changed the core so that it does not accept zero resolutions. Additionally I have changed all plug-ins that try to set the resolution to check the value and simply don't set it at all if it is invalid. Gimp will then use the default set up by the user. Salut, Sven
Re: [gimpwin-users] PNG blank display bug
I have changed the core so that it does not accept zero resolutions. Additionally I have changed all plug-ins that try to set the resolution to check the value and simply don't set it at all if it is invalid. Gimp will then use the default set up by the user. Please make sure that XCF loading is not exempt from these checks. (XCF loads seem to bypass core sanity checking sometimes..) Thanks for the tip. It looks like XCF did it right this time and by looking at it I found that we have definitions for GIMP_MIN_RESOLUTION and GIMP_MAX_RESOLUTION. So the core now checks for these bounds. I have again removed the checks from the plug-ins since this only bloats the plug-in code. Salut, Sven Kelly
Re: [gimpwin-users] PNG blank display bug
On Sat, Jan 08, 2000 at 11:16:45AM +0200, Tor Lillqvist wrote: The PNG apparently claims to have the display (and print) resolution of 0 pixels/inch... Set it with ImageScale ImagePrint Size Display UnitResolution X and Y and the image appears. The PNG plug-in probably should check for this and use some sensible default if the file claims 0 dpi? Mmmm. Can someone tell me which app or lib is settings pHYs == 0 ? I think png-implement would like to know about anyone stupid enough to actually do that (it's an optional chunk, so if you don't know what to put in it, why write it at all?) If you have a suitably broken PNG which is non-sensitive then I'd also like a copy to add to my collection of test images. Nick.
