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

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!


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...]


            (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
            (1a) Subclassing GtkButton and force it to allocate the
            size of the
            GtkImage it contains and overwrite all its drawing
            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.
            a new button widget can cause deviation in functionalities
            in future
            GTK+ releases and I want to avoid if there is a better

            I am hoping someone would point out to me an easier way to

            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
            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
        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.


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