Valid GDisplay and GImage values

[Dave Neary]

Hi all.

I'm looking at fixing bug #22567 (bugzilla number). Scaling an 
image and undoing it when the image has pretty extreme 
dimensions causes problems - and it's shown up something in 
gdisplay_shrink_wrap which is the source of the problem - I was 
just wondering if you guys could put me straight on whether this 
behaviour is ever acceptable.

For a given display gdisp, you're getting (after a change in 
size of the image) gdisp-gimage-height  
gdisp-gdisp-disp_height which is causing problems with 
shrink_wrap wqhen it tries to set borders less than zero, and 
sometimes to such an extent that gdisp-gimage-width + 
gdisp-shell_width - gdisp-disp_width  0 , resulting in 
gtk_allocate_image being called with a large unsigned value, 
rather than a reasoable one.

I think I have an idea what's hapenning, but I just wanted to 
clear up what each of these actually mean, and what kind of 
relationships are always true (or should always be true) in 
relation to them. 

Thanks a lot,
Dave.

-- 
  .--.
 /  David Neary,  \
| E-Mail [EMAIL PROTECTED] | 
 \ Phone +353-1-872-0654  /
  `--'

Bug fix for #37633

[Dave Neary]

Hi all,

I have already attached this to bugzilla, but since I'm not sure 
how quick the uptake is on fixes submitted in that way (and 
since it's small), I'll send it here too :)

This basically make File-Revert work right after a display has 
been re-sized.

Cheers,
Dave.

-- 
  .--.
 /  David Neary,  \
| E-Mail [EMAIL PROTECTED] | 
 \ Phone +353-1-872-0654  /
  `--'


Index: fileops.c
===
RCS file: /cvs/gnome/gimp/app/fileops.c,v
retrieving revision 1.137
diff -u -r1.137 fileops.c
--- fileops.c   2001/02/07 15:01:51 1.137
+++ fileops.c   2001/02/13 15:34:39
@@ -2050,6 +2050,9 @@
{
  undo_free (new_gimage);
  gdisplays_reconnect (old_gimage, new_gimage);
+ gdisplays_resize_cursor_label (new_gimage);
+ gdisplays_update_full (new_gimage);
+ gdisplays_shrink_wrap (new_gimage);
  gimp_image_clean_all (new_gimage);
}
   else if (status != PDB_CANCEL)

Re: RFC: unified system of PaintObjects (long)

[Austin Donnelly]

On , 9 Feb 2001, Jens Lautenbacher wrote:

 Therefore I propose to completely rewrite everything that can be
 considered a "PaintObject" into a generic provider form, where the
 paintcore for each operation asks the provider for it's data.

It would be nice to be able to use loadable modules to implement new
"providers", so that the first cut can ignore natural media, but then
(eg Raph?) can add them later as a module.

Basically, make it a nice harness for the people playing with
watercolour simulators etc to use. 

Austin