Re: (1) How to implement Image Buttons without gaps? (2) Can GtkImage stretch an image automatically?
- From: "Milosz Derezynski" <internalerror gmail com>
- To: "Daniel Yek" <dyek real com>
- Cc: gtk-devel-list gnome org
- Subject: Re: (1) How to implement Image Buttons without gaps? (2) Can GtkImage stretch an image automatically?
- Date: Thu, 21 Aug 2008 06:07:54 +0200
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.
2008/8/21 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.
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]