Re: Bonobo resize broken?

On Wed, 9 May 2001, Michael Meeks wrote:
> On Wed, 9 May 2001, Jens Finke wrote:
> > if one loads an image in Eye of Gnome (CVS head, bonobo version), the
> > window won't be resized to the image size. This behaviour is really
> > bad and I am about to fix it.
>         The Image size could be massive, like 3000x2000 - I really don't
> think you want to size the window to that.

Sure it can be. But most of the times it isn't and the user must resize
the window manually, which is really annoying.

>         Off the top of my head, it looks like you might be using the
> Embeddable interface instead of the Control interface.
>         Please use the Control interface. The EOG Control should render
> scroll bars, and do all the nice EOG zooming and panning for you.

I'am using the control.

> > If I ask the control by hand which size it desires (through the
> > getDesiredSize method) it tells me the correct size of the image. But
> > the ControlFrame/BonoboWindow doesn't recognize it and nothing else
> > happens. Especially the main window doesn't increase its size.
>         Determining the size of something contained in a semi-infinite
> scrolled, zoomable area is pretty meaningless - what size ? at what zoom ?
> etc.

I don't know any image viewer which lets you resize the window manually
every time you load an image. They all determine a good window size
according to the screensize and calculate the appropriate zoom factor for
the image.  This is what I want for EoG.

> > I've tried to call the queueResize method on the ControlFrame but this
> > method does nothing and contains only the comment that the GTK system
> > take care of this. Can anybody give me some hints how this bonobo
> > getDesiredSize/setSize/queueResize system works?
>         the getDesiredSize / setSize are deprecated, please use the gtk
> sizing mechanism instead. If you want to do something really cunning, I
> would strongly suggest adding an 'eog:image_x' and 'eog:image_y'
> properties to the EOG Control's PropertyBag if they are not there already.

Ok, I will try the pure GTK stuff tonight and add the properties (AFAIK
they are not there). What about adding a "deprecated" flag to the API?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]