Re: gtk_widget_set_size_request stopped working with GTK3
It's the same error I am experiencing when I am trying to make my ListView ctrl scrolled without using the ScrolledWindow. It works in GTK+2 but really not in GTK+3. What I was trying to do is to request it to be smaller or else when the list gets longer it force its self to show all the list out of boundary. I notice that when you didn't even try to resize the column you can still change the size of the window, but once you touch or chage any column's size, the size of the list adjust to the minimum size. I wonder if this bug is already fix or have any solution for this since this post is quite late. Anyway, at this moment in my GTK+3 it still doesn't work. -- View this message in context: http://gtk.10911.n7.nabble.com/gtk-widget-set-size-request-stopped-working-with-GTK3-tp26274p84314.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
It's the same error I am experiencing when I am trying to make my ListView ctrl scrolled without using the ScrolledWindow. It works in GTK+2 but really not in GTK+3. What I was trying to do is to request it to be smaller or else when the list gets longer it force its self to show all the list out of boundary. I notice that when you didn't even try to resize the column you can still change the size of the window, but once you touch or chage any column's size, the size of the list adjust to the minimum size. I wonder if this bug is already fix or have any solution for this since this post is quite late. Anyway, at this moment in my GTK+3 it still doesn't work. -- View this message in context: http://gtk.10911.n7.nabble.com/gtk-widget-set-size-request-stopped-working-with-GTK3-tp26274p84317.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Mike, On Wed, Apr 16, 2014 at 11:25 PM, mike_s michael.u.santi...@gmail.com wrote: It's the same error I am experiencing when I am trying to make my ListView ctrl scrolled without using the ScrolledWindow. It works in GTK+2 but really not in GTK+3. What I was trying to do is to request it to be smaller ... And this is precisely the issue. With GTK+3 we enforce size request rules a little more strongly than we did in GTK+2. A widget may not, under any circumstances, ever be allocated a size which is LESS than the widget's original request. The documentation of gtk_widget_set_size_request() does specify[0] this: Sets the minimum size of a widget; that is, the widget’s size request will be at least width by height . You can use this function to force a widget to be larger than it normally would be. If you need to force a widget to be smaller, then it needs to actually request less space. If what you need is a GtkScrolledWindow without scrollbars, you could use a GtkViewport for this directly. The viewport will take care of allocating enough space for the child widget's content while only displaying the portion of the child that you want displayed (this can be achieved by driving the GtkAdjustements which are associated to the viewport). Cheers, -Tristan [0]:https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-size-request or else when the list gets longer it force its self to show all the list out of boundary. I notice that when you didn't even try to resize the column you can still change the size of the window, but once you touch or chage any column's size, the size of the list adjust to the minimum size. I wonder if this bug is already fix or have any solution for this since this post is quite late. Anyway, at this moment in my GTK+3 it still doesn't work. -- View this message in context: http://gtk.10911.n7.nabble.com/gtk-widget-set-size-request-stopped-working-with-GTK3-tp26274p84317.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On Fri, Oct 5, 2012 at 1:57 AM, Steffen Gutmann muib...@yahoo.com wrote: Hi Tristan! Right, the bug might have to do more with cropping/scaling support GtkImage, rather than it's size request. Filed as [Bug 685506] New: GtkImage and size/space management Regarding size request: We add a new property of type boolean to GtkImage. If it is set (default), the size request for GtkImage will be the size of the underlying image (or the pixel-size), i.e. the exact same behaviour as it is now. If it is set to FALSE then the minimum size will be (1, 1) and an application can use width-request and height-request for making the widget size larger. I am not sure what a good name for this new property would be, but maybe you have a suggestion?. Something like min-size-is-image-size would probably make the property self-explanatory but is obviously too long compared to other existing property names. Maybe full-image or image-size-request? Any comment about how to allow a smaller size request? Any good name for this property? Regading placement: In GTK2, GtkImage cropped the image such that only the center is shown, i.e. it took off an equal amount of image content on the left and right, and top and bottom. It probably just sets the right clipping mask when drawing the image for achieving this. We could simply use the same policy, or we modify the usage of GtkWidget's halign and valign properties. Currently the docs reads: halign GtkAlign : Read / Write While it's true that the align properties make no sense when the widget's natural size is equal to, or exceeds the widget's allocation; From a programmer's point of view, the align properties also make sense when the widget size is smaller than its allocation. For example, for centering, one would draw the contents at (allocation.width/height - contents.width/height) / 2 which works in both cases, when there is extra space as well when there is insufficient space (assuming clipping is done by cairo correctly). I'm not exactly sure it's a good idea to use the GtkWidget's halign/valign properties directly (i.e. it's like hidden candy, people wont see it evidently in the docs/headers for GtkImage and so will probably not discover it). We could cross-ref the halign/valign properties in the docs of above new property that describes how to obtain a smaller size request for GtkImage. However I do like the idea of GtkAlign properties for that, where FILL would mean scale and CENTER/START/END have the obvious clipping behaviors. Right. Actually I tried the FILL alignment with a GtkImage having extra space. The image becomes centered but not streched. For keeping compatibility, I guess we want to keep it this way. Also, it should have reasonable behaviors defined for the various configurations of a GtkImage I think we are shooting too far here. For icons and such I think the pixel-size property is the right approach and the new property suggested above should have no effect. Otherwise, if we are trying to support all combinations of configurations, pixel-sizes and the new property then we will likely end up in open problems and the chance that any patch will be accepted is going to be small. I disagree with this. What we definitely want to avoid in GTK+, is overextending the API in ways that only apply to special case configurations (remember that in most cases, once you introduce a new API it can not be removed in a later release, this imposes more and more constraints on code maintainability in the long term). i.e., it's already annoying that pixel-size only applies to an icon loaded from the icon theme (and so if we were to add some scaling/cropping features that are more general, it would be better to deprecate the pixel-size property if the same effect can be achieved with a newer API). It's a priority for the API to be readable, and to avoid additions of properties which introduce 'crowding' into the api, we should keep GTK+ API as short and sweet as possible. Yes, that requires more thought and consideration when writing platform code, that pays off when the user is satisfied that user facing apis such as pixel-size does what it says; regardless of other property settings. If for instance, it is not possible to respect a property for a given configuration of a widget, or it clutters the code to much and the code becomes unreadable due to the attempt to manage all configurations, then a good approach to that problem is to introduce subclasses to handle that in a sensible way (i.e. it would have probably made sense originally that only the GtkImageIconTheme subclass exports a 'pixel-size' property) Like for instance, how we've split out the convenience apis for GtkComboBox into a separate GtkComboBoxText class. For now I think we've taken up enough valuable list space and should probably move this conversation to the bug report. Regards,
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan!
I suggest you start by filing an enhancement bug against GtkImage for this.
Yes, I can do that. Just to make sure, I file a new bug for component gtk,
severity set to enhancement, and put somethign like Size request of GtkImage
into the title. Is this correct?
If you have a patch to propose, here would be a good place to discuss
the proposed new apis.
I might also be able to work on this and provide a patch. Before starting on
this, how about the following changes:
Regarding size request:
We add a new property of type boolean to GtkImage. If it is set (default), the
size request for GtkImage will be the size of the underlying image (or the
pixel-size), i.e. the exact same behaviour as it is now. If it is set to FALSE
then the minimum size will be (1, 1) and an application can use width-request
and height-request for making the widget size larger. I am not sure what a
good name for this new property would be, but maybe you have a suggestion?.
Something like min-size-is-image-size would probably make the property
self-explanatory but is obviously too long compared to other existing property
names. Maybe full-image or image-size-request?
Regading placement:
In GTK2, GtkImage cropped the image such that only the center is shown, i.e. it
took off an equal amount of image content on the left and right, and top and
bottom. It probably just sets the right clipping mask when drawing the image
for achieving this. We could simply use the same policy, or we modify the
usage of GtkWidget's halign and valign properties. Currently the docs
reads:
halign GtkAlign : Read / Write
How to distribute horizontal space if widget gets extra space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with extra space in a single (x or y)
dimension.
Alignment only matters if the widget receives a too large allocation,
for example if you packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch to fill all space if possible, center if no meaningful
way to stretch
GTK_ALIGN_START snap to left or top side, leaving space on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space on left or top
GTK_ALIGN_CENTER center natural width of widget inside the allocation
My suggestion is to make halign and valign also deal with the case where the
content of the widget is larger than the allocated space. The modified docs
would then read:
halign GtkAlign : Read / Write
How to distribute horizontal space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with space in a single (x or y)
dimension.
Alignment only matters if the widget receives a too large or too small
allocation,
for example if you packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space. Likewise, if you have a 100x100 image
inside a 20x20 space
then the image could be scaled down, only the center part of the image be
shown, or it could
be cropped to the top left or bottom right part.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch or shrink to fill all space if possible, or center if no
meaningful way to scale
GTK_ALIGN_START snap to left or top side, leaving space or cropping widget
content on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space or cropping widget
content on left or top
GTK_ALIGN_CENTER center widget inside the allocation
Steffen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On Thu, Oct 4, 2012 at 1:46 AM, Steffen Gutmann muib...@yahoo.com wrote:
Hi Tristan!
I suggest you start by filing an enhancement bug against GtkImage for this.
Yes, I can do that. Just to make sure, I file a new bug for component gtk,
severity set to enhancement, and put somethign like Size request of
GtkImage into the title. Is this correct?
Right, the bug might have to do more with cropping/scaling support in
GtkImage, rather than it's size request.
If you have a patch to propose, here would be a good place to discuss
the proposed new apis.
I might also be able to work on this and provide a patch. Before starting on
this, how about the following changes:
Regarding size request:
We add a new property of type boolean to GtkImage. If it is set (default),
the size request for GtkImage will be the size of the underlying image (or
the pixel-size), i.e. the exact same behaviour as it is now. If it is set to
FALSE then the minimum size will be (1, 1) and an application can use
width-request and height-request for making the widget size larger. I am
not sure what a good name for this new property would be, but maybe you have
a suggestion?. Something like min-size-is-image-size would probably make
the property self-explanatory but is obviously too long compared to other
existing property names. Maybe full-image or image-size-request?
Regading placement:
In GTK2, GtkImage cropped the image such that only the center is shown, i.e.
it took off an equal amount of image content on the left and right, and top
and bottom. It probably just sets the right clipping mask when drawing the
image for achieving this. We could simply use the same policy, or we modify
the usage of GtkWidget's halign and valign properties. Currently the
docs reads:
halign GtkAlign : Read / Write
While it's true that the align properties make no sense when the
widget's natural size is equal to,
or exceeds the widget's allocation; I'm not exactly sure it's a good
idea to use the GtkWidget's
halign/valign properties directly (i.e. it's like hidden candy, people
wont see it evidently in
the docs/headers for GtkImage and so will probably not discover it).
However I do like the idea of GtkAlign properties for that, where FILL
would mean scale
and CENTER/START/END have the obvious clipping behaviors.
It would have to deal well with situations where the user asked the
image to scale (FILL)
horizontally but to clip vertically ;-)
Also, it should have reasonable behaviors defined for the various
configurations of
a GtkImage (i.e, how does GtkIconSize fit into this ? does it make
sense to allow
the image to try loading the given icon at different sizes to satisfy
the allocation ?
naturally the natural size of the image would have to still be determined by the
user specified icon size, in the case that GtkImage be allocated extra space,
should a larger icon size be tried ? and should the image be upscaled as
a fallback or in situations where the source is a GdkPixbuf ?)
If you're serious about working on this, I would open an enhancement bug
and put your ideas there. You'll be sure to receive more feedback if you do
provide a patch with some test cases showing how it works.
Cheers,
-Tristan
How to distribute horizontal space if widget gets extra space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END,
GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with extra space in a single (x or y)
dimension.
Alignment only matters if the widget receives a too large allocation,
for example if you packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch to fill all space if possible, center if no meaningful
way to stretch
GTK_ALIGN_START snap to left or top side, leaving space on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space on left or top
GTK_ALIGN_CENTER center natural width of widget inside the allocation
My suggestion is to make halign and valign also deal with the case where the
content of the widget is larger than the allocated space. The modified docs
would then read:
halign GtkAlign : Read / Write
How to distribute horizontal space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END,
GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with space in a single (x or y)
dimension.
Alignment only matters if the widget receives a too large or too small
allocation,
for example if you packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space.
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan! Lets not go around the merry-go-round one more time. In GTK+3, widgets receive *at least* what they requested in the size requesting phase. User facing apis cannot undermine the minimal requirements for the geometry which a widget has requested. User facing apis can however, enforce a minimum size (i.e. the widget will be at least this big) or they can configure a widget in such a way that it will require less size. Ok, I accept this statement. Will the docs of gtk_widget_set_size_request be updated accordingly? For GtkImage though, I think we need some way to specify the minimum size when a GdkPixbuf is used. The pixel-size thing not working for pixbufs could be considered an enhancement request bug for GtkImage. i.e. it should support clipping of pixbufs (and then, it should also need some alignment parameters to decide which portion of the input image should be clipped, also pixel-size does not really imply clipping directly, the user might very well expect the image to scale to the desired size). The docs for gtk_image_set_pixel size says: Sets the pixel size to use for named icons. If the pixel size is set to a value != -1, it is used instead of the icon size set by gtk_image_set_from_icon_name(). This is not really clear to me. Does it scale the image to the desired pixel size, or center or crop them? This should be specified in the docs. Also for a GtkImage based on a GdkPixbuf, don't we want to support different values for width and height? The pixel size only specifies one dimension. Are the icons always of a squared size? Maybe two new properties in GtkImage would do the job, say pixbuf-width-request and pixbuf-height-request. They would do the same thing as width-request and height-request in GTK2. Or, say we allow shrinking of the size in width-request and height-request but only if an additional new property size-request-enforce (boolean, default is FALSE) is set to TRUE. Regarding alignment, the halign and valign properties in GtkWidget may be useful. Although they currently are only meaningful when there is extra space, not when the content of the Widget is larger than the allocated space. a.) Create a GtkDrawingArea b.) Connect to draw signal c.) Use this code: gdk_cairo_set_source_pixbuf (cr, pixbuf, x, y); cairo_paint (cr); (borrowed directly from: Yes, that works. Thanks! Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On Tue, Oct 2, 2012 at 1:52 AM, Steffen Gutmann muib...@yahoo.com wrote: Hi Tristan! Lets not go around the merry-go-round one more time. In GTK+3, widgets receive *at least* what they requested in the size requesting phase. User facing apis cannot undermine the minimal requirements for the geometry which a widget has requested. User facing apis can however, enforce a minimum size (i.e. the widget will be at least this big) or they can configure a widget in such a way that it will require less size. Ok, I accept this statement. Will the docs of gtk_widget_set_size_request be updated accordingly? Yes, I'll take care of it tonight. For GtkImage though, I think we need some way to specify the minimum size when a GdkPixbuf is used. The pixel-size thing not working for pixbufs could be considered an enhancement request bug for GtkImage. i.e. it should support clipping of pixbufs (and then, it should also need some alignment parameters to decide which portion of the input image should be clipped, also pixel-size does not really imply clipping directly, the user might very well expect the image to scale to the desired size). The docs for gtk_image_set_pixel size says: Sets the pixel size to use for named icons. If the pixel size is set to a value != -1, it is used instead of the icon size set by gtk_image_set_from_icon_name(). This is not really clear to me. Does it scale the image to the desired pixel size, or center or crop them? This should be specified in the docs. Also for a GtkImage based on a GdkPixbuf, don't we want to support different values for width and height? The pixel size only specifies one dimension. Are the icons always of a squared size? Maybe two new properties in GtkImage would do the job, say pixbuf-width-request and pixbuf-height-request. They would do the same thing as width-request and height-request in GTK2. Or, say we allow shrinking of the size in width-request and height-request but only if an additional new property size-request-enforce (boolean, default is FALSE) is set to TRUE. Regarding alignment, the halign and valign properties in GtkWidget may be useful. Although they currently are only meaningful when there is extra space, not when the content of the Widget is larger than the allocated space. I suggest you start by filing an enhancement bug against GtkImage for this. If you have a patch to propose, here would be a good place to discuss the proposed new apis. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
When creating a new widget subclass, you end up implementing get_preferred_height/width. This allows you to specify both a minimum and a natural size. Then in on_size_allocate() you can decide to maybe set a clipped or scaled version of your pixbuf to a GtkImage. When you do it this way, you don't need to put the image in a scrolled window either. Its a shame there are only methods to expose the minimum width and not also the natural width on the default widgets, but I'd guess its difficult to abstract across all widgets. But it does seem like GtkImage should at least expose the natural width, as it seems like a common problem one would have with pictures. On Fri, Sep 28, 2012 at 11:28 PM, Tristan Van Berkom t...@gnome.org wrote: Lets not go around the merry-go-round one more time. In GTK+3, widgets receive *at least* what they requested in the size requesting phase. User facing apis cannot undermine the minimal requirements for the geometry which a widget has requested. User facing apis can however, enforce a minimum size (i.e. the widget will be at least this big) or they can configure a widget in such a way that it will require less size. The pixel-size thing not working for pixbufs could be considered an enhancement request bug for GtkImage. i.e. it should support clipping of pixbufs (and then, it should also need some alignment parameters to decide which portion of the input image should be clipped, also pixel-size does not really imply clipping directly, the user might very well expect the image to scale to the desired size). On Sat, Sep 29, 2012 at 2:28 AM, Steffen Gutmann muib...@yahoo.com wrote: [...] Here is what I am trying to do. I have an image. The center part of the image contains a logo that I want to display to the user. Around the center part there is little extra content that is not important but nice to have. With GTK2 I set the min size (properties with-request and height-request) to just about the size of the logo, place the GtkImage into a GtkWindow, set the default size of the GtkWindow to slightly larger than the min size but smaller than the fulll size of the image, make the window resizable, and show it to the user. GtkImage in GTK2 automatically clipped the image and centered it. The user can enlarge the window and see more of the image, or shrink it down to the min size where only the logo stays visible. I have not found a way yet to achive the same with GTK3. a.) Create a GtkDrawingArea b.) Connect to draw signal c.) Use this code: gdk_cairo_set_source_pixbuf (cr, pixbuf, x, y); cairo_paint (cr); (borrowed directly from: http://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html) The above should pretty much get you what you want, just consider the widget's allocation at draw time and use that to offset the given x,y for gdk_cairo_set_source_pixbuf(). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
Lets not go around the merry-go-round one more time. In GTK+3, widgets receive *at least* what they requested in the size requesting phase. User facing apis cannot undermine the minimal requirements for the geometry which a widget has requested. User facing apis can however, enforce a minimum size (i.e. the widget will be at least this big) or they can configure a widget in such a way that it will require less size. The pixel-size thing not working for pixbufs could be considered an enhancement request bug for GtkImage. i.e. it should support clipping of pixbufs (and then, it should also need some alignment parameters to decide which portion of the input image should be clipped, also pixel-size does not really imply clipping directly, the user might very well expect the image to scale to the desired size). On Sat, Sep 29, 2012 at 2:28 AM, Steffen Gutmann muib...@yahoo.com wrote: [...] Here is what I am trying to do. I have an image. The center part of the image contains a logo that I want to display to the user. Around the center part there is little extra content that is not important but nice to have. With GTK2 I set the min size (properties with-request and height-request) to just about the size of the logo, place the GtkImage into a GtkWindow, set the default size of the GtkWindow to slightly larger than the min size but smaller than the fulll size of the image, make the window resizable, and show it to the user. GtkImage in GTK2 automatically clipped the image and centered it. The user can enlarge the window and see more of the image, or shrink it down to the min size where only the logo stays visible. I have not found a way yet to achive the same with GTK3. a.) Create a GtkDrawingArea b.) Connect to draw signal c.) Use this code: gdk_cairo_set_source_pixbuf (cr, pixbuf, x, y); cairo_paint (cr); (borrowed directly from: http://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html) The above should pretty much get you what you want, just consider the widget's allocation at draw time and use that to offset the given x,y for gdk_cairo_set_source_pixbuf(). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan I must admit the docs are incorrect about this, it says: Sets the minimum size of a widget; that is, the widget's size request will be width by height. You can use this function to force a widget to be either larger or smaller than it normally would be. But what it should say: Sets the minimum size of a widget; that is, the widget's size request will be width by height. You can use this function to force a widget to be larger than it normally would be. Thanks for the clarification. Although, I am not convinced that restricting it to only allow enlarging the min size is desirable. If an application really wants to make a widget smaller and accepts that content may get clipped, why not allowing gtk_widget_set_size_request setting a smaller size, like it was in GTK2? In other words, as Cosimo already mentioned in the report, a widget can never be smaller than the minimum size reported by the implementation. He also mentioned that you can configure that particular widget to actually be smaller. The suggested solution was using the pixel-size property which does not do anything when using a GdkPixBuf as image. The min size of the GtkImage will be the size of the GdkPixBuf. If that one is large, so will be the GtkImage. If an application accepts image filenames typed in by a user, and thus does not know a-priori the size of an image, the GtkImage might spawn a size larger than the screen. Two other options are: o If you cant display the whole widget, put it in a scrolled window I tried that as well. When using the GTK_POLICY_NEVER scrollbar policy, the min size of the GtkScrolledWindow becomes the min size of the GtkImage. o Use clutter-gtk library to put the GtkWidget one a stage and then scale it and transform it to the desired size ;-) I would prefer not using additonal libs and don't need any scaling or transformations, just clipping and centering. Here is what I am trying to do. I have an image. The center part of the image contains a logo that I want to display to the user. Around the center part there is little extra content that is not important but nice to have. With GTK2 I set the min size (properties with-request and height-request) to just about the size of the logo, place the GtkImage into a GtkWindow, set the default size of the GtkWindow to slightly larger than the min size but smaller than the fulll size of the image, make the window resizable, and show it to the user. GtkImage in GTK2 automatically clipped the image and centered it. The user can enlarge the window and see more of the image, or shrink it down to the min size where only the logo stays visible. I have not found a way yet to achive the same with GTK3. Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_widget_set_size_request stopped working with GTK3
Hi, with GTK2 some applications used to set the minimum size of some widgets using gtk_widget_set_size_request. E.g. the min size of a GtkImage. This no longer works with GTK3 and the min size of the GtkImage is that of the underlying image, e.g. a GdkPixbuf. There is also a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=670068 Is gtk_widget_set_size_request broken? Or how is an application supposed to set (or override if the app knows better) the min size? Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On 09/28/2012 02:16 AM, Steffen Gutmann wrote: Hi, with GTK2 some applications used to set the minimum size of some widgets using gtk_widget_set_size_request. E.g. the min size of a GtkImage. This no longer works with GTK3 and the min size of the GtkImage is that of the underlying image, e.g. a GdkPixbuf. There is also a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=670068 Is gtk_widget_set_size_request broken? Or how is an application supposed to set (or override if the app knows better) the min size? gtk_widget_set_size_request() I must admit the docs are incorrect about this, it says: Sets the minimum size of a widget; that is, the widget's size request will be/|width|/by/|height|/. You can use this function to force a widget to be either larger or smaller than it normally would be. But what it should say: Sets the minimum size of a widget; that is, the widget's size request will be/|width|/by/|height|/. You can use this function to force a widget to be larger than it normally would be. In other words, as Cosimo already mentioned in the report, a widget can never be smaller than the minimum size reported by the implementation. He also mentioned that you can configure that particular widget to actually be smaller. Two other options are: o If you cant display the whole widget, put it in a scrolled window o Use clutter-gtk library to put the GtkWidget one a stage and then scale it and transform it to the desired size ;-) Cheers, -Tristan disclaimerThis email may reach you with EVIL HTML formatting which of course has no place in emails... for some config reasons TB needed to be used instead of Evo... and I still have to find the switch to NUKE EVIL HTML from emails/disclaimer Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
