Re: gtk 1.2.4 breaks my applications :(

[Owen Taylor <otaylor redhat com>]

Rasca Gmelch <thron@gmx.de> writes:

> hi owen,
>  
> > Rasca Gmelch <thron@gmx.de> writes:
> > 
> > > in my app i create first a toplevel and a box widget. then i
> > > call gtk_widget_show() cause i need a window to create pixmaps.
> > > then i add other widgets. the problem with 1.2.4 is that
> > > the toplevel will not be resized after the _show() call also
> > > if i add other diffent widgets to the box widget :-((
> > > 
> > > is that a bug or a feature of gtk+? according to the changelog
> > > there changed some thing with the geometry management.. i
> > > think it's not a good idea to change the gtk+ lib in a way that
> > > it breaks current programs.
> > 
> > If your program worked with 1.2.3 and doesn't work with
> > 1.2.4, then its a bug. (We are still actually struggling
> > a bit with gtkwindow.c and will put out a 1.2.5 shortly).
> 
> i've found that 1.2.4 also breaks "gvim" a gtk+ version
> of vim. starting with a existing file gives me a small
> window instead of the usual size.
> 
> i also found an other strange problem which does *not*
> exists if i only install 1.2.4 (btw. the programs are
> using the shared libs). *but* if i recompile my programs
> with the new gtk+ installation it is there:
> drag and drop from my filemanager to my application panel
> does not work.. !?

Can you give more details? Drag-and-drop did change
a bit between 1.2.3 and 1.2.4, but I've extensively
tested the new code.
 
> > Code that demonstrates the problem here would be much 
> > appreciated. 
> 
> here is a small example which should work with 1.2.3
> but not 1.2.4: with 1.2.3 it gives me 3 buttons as
> i would expect. in 1.2.4 the three buttons are *very*
> narrow (no resizing for button 2 and 3 after the toplevel
> is shown). the original program is was talking about
> could be found at http://home.pages.de/~rasca/xap-0.7.8.tar.gz
 
OK, thanks for the example. This will definitely be fixed
in 1.2.5.

[
  Tim, this is the race condition that you thought wouldn't
  occur in practice. :-) The problem here is that
  gtk_window_move_resize() is getting called from the
  configure event with handling_resize=TRUE, and then that
  is clearing the toplevel from the resize queue, but not
  properly handling the new size.
]
 
> > [ That being said, there are much better ways of making
> >   pixmaps than prematurely showing your toplevel windows.
> 
> i'm was sure there is a better way to do it. but until
> no i wasn't be able to find a good example. in testgtk.c
> and in the html-docu they allways use a window to create
> a pixmap and don't use the *_colormap_*() functions.
> please could you fill in some example lines:

This has been gone over a lot of times on gtk-list,
but nobody has ever updated the FAQ or tutorial.
 
>  char *pixfile = "foo.xpm";
>  GtkWidget *top, *box, *btn, *pixw;
>  GdkPixmap *pixmap, *pixmap_mask;
>  GdkColor background;
> 
>  top = gtk_window_new (GKT_WINDOW_TOPLEVEL);
>  box = gtk_hbox_new (FALSE, 4);
>  gtk_conainer_add (GTK_CONTAINER(top), box);
> 

  pixmap = gtk_pixmap_colormap_create_from_xpm (
           NULL, gtk_widget_get_colormap (top),
           &pixmap_mask, NULL, pixfile);
  pixw = gtk_pixmap_new (pixmap, pixmap_mask);
  gdk_pixmap_unref (pixmap);
  gdk_pixmap_unref (pixmap_mask);

> ... ??
> 
>  btn = gtk_button_new ();
>  gtk_container_add (GTK_CONTAINER(btn), pixw);
>  gtk_box_pack_start (GTK_BOX(box), btn, TRUE, TRUE, 2);

Regards,
                                        Owen