Re: (1) How to implement Image Buttons without gaps? (2) Can GtkImage stretch an image automatically?

[Daniel Yek <dyek real com>]

Christian Dywan wrote:
> Am Wed, 20 Aug 2008 17:07:00 -0700
> schrieb Daniel Yek <dyek real com>:
>
>   
> > [I sent this gtk-app-devel-list earlier, but I suppose this list
> > might have an answer for me.
> > I'm just trying to figure things out...]
> >
> > Hi,
> >
> > (1) I have been looking for a way to use GtkButton to create an Image
> > Button that is exactly of the same size as the GtkImage that it
> > contains, so that two Image Buttons next to each others would leave no
> > gap in between.
> >
> > I have some ideas in mind, but I wonder if I'm going to
> > over-engineering them and if there is a well-known approach to solve
> > this, supposedly, common problem.
> >
> > For this first issue, this is the main idea that I am considering to
> > investigate:
> > (1a) Subclassing GtkButton and force it to allocate the size of the
> > GtkImage it contains and overwrite all its drawing functionalities
> > that cause non-image area to appear around GtkImage. If focus or
> > default lines are to be drawn, draw them on the inside edge of
> > GtkImage or suppress them entirely if necessary.
> >
> > I haven't looked into GtkButton source code lately, but I think this
> > approach can potentially boil down to reimplementing the entire button
> > from scratch to derive from GtkWidget, if GtkButton turns out to not
> > allow a subclass to override certain drawing function. Reimplementing
> > a new button widget can cause deviation in functionalities in future
> > GTK+ releases and I want to avoid if there is a better solution
> > available.
> >
> > I am hoping someone would point out to me an easier way to accomplish
> > this.
> >
> > If GtkButton simply is not able to function as Image Buttons without
> > gap, I wonder if GTK+ developers considered the usage during the
> > process of GtkButton implementation/development? I wonder if the
> > usage model was intentionally excluded (for reasons that I am
> > obviously not sure of -- maybe for memory efficiency reasons; or for
> > theming reasons)? Or is it simply the case that it wasn't implemented
> > yet? Or is this usage model really unusual?
> >     
>
> Hey Daniel,
>
> you are not the first person with such a question, I see people asking
> that in the IRC about once a month.
>
> Basically you should not try to use a button only to try to suppress
> all its functionality, and that is what you are trying to do here. A
> button that draws only an image but not any other features of a button
> can just as well be that, an image.
>   
> So the solution is as simple as putting an image in an event box and
> connecting your signals. Unless there's a special requirement you
> didn't mention, that's all you need.
>   
Hi Christian,

I tried the event box with images, but this will not have all the 
behavior that GtkButton has -- it probably can't be put into a 
GtkButtonBox too. It is a solution, but I was hoping to keep GtkButton's 
behaviors as much as possible, except to replace its appearance with a 
set of images for designs that are demanding this.

The Image-cum-Event Box is a very degenerated "button" -- it will not 
have the same interfaces that a GtkButton has, unless I reimplement all 
that I need. Subclassing would keep all the interfaces intact, but as I 
said, I'm not sure yet (until I spent enough time on it) if subclassing 
alone is going to be enough.

Thanks for the comment. At least now I know that this need is not that 
unusual.

--
Daniel Yek.



> ciao,
>     Christian
>