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

[Daniel Yek <dyek real com>]

Milosz Derezynski wrote:
> Subclassing GtkButton pretty much works, but you will need to override 
> expose and all size-related functions; the semantics of GtkButton will 
> be handler by what's already in GtkButton, you then just need to make 
> use of state data.

Thanks! That makes me feel hopeful!

--
Daniel.


> 2008/8/21 Daniel Yek <dyek real com <mailto:dyek real com>>
>
>
>     Christian Dywan wrote:
>
>         Am Wed, 20 Aug 2008 17:07:00 -0700
>         schrieb Daniel Yek <dyek real com <mailto: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
>