Re: Zoom/magnification of images in GDK
Hello Now, I know how I could do this if I used gtkglext to get OpenGL in the picture, so I could throw the image into a texture and then render it at an arbitrary size. But I was wondering if there were any options built into GTK/GDK which would allow me to avoid the extra dependency? There are three options that I can remember now: 1. Convert your gray pixels into GdkPixbuf and then scale it using gdk_pixbuf_scale() to proper size, then draw it. 2. Convert your gray pixels into GdkPixbuf and then scale it using cairo directly when drawing. 3. Convert your gray pixels into CairoImageSurface and then scale it using cairo directly when drawing. Those three methods won't require you to add any additional dependencies, since everything listed above is part of the standard GTK+ installation. Tadej -- Tadej Borovšak tadeboro.blogspot.com tadeb...@gmail.com tadej.borov...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Extended Layout incubator branch.
Good morning, I've managed to get the base feature set of the native-layout branch working and in a usable state. By usable I mean: I've been running Glade on the extended layout branch for the past week and all of the regressions I've spotted so far have been fixed, I can also run the Gimp and gedit with no visible regressions yet (and ofcourse, the gtk-demo and testgtk as well). It should also of course essentially solve the height-for-width bug[0] and at least provide the right framework to adress the GtkExpander ellipsize bug[1] and probably a few more. I also spent some time today documenting the API which makes alot more sense now (at least to me) I've salvaged everything that is clean and usable thus far into a new 'native-layout-incubator' branch. This branch was created for the review process and potential inclusion of the whole height-for-width geometry management system and modest feature set to leverage it. Anyone interested should try compiling the incubator branch (or the native-layout branch even) and run the example in the tests directory: ./tests/extendedlayoutexample (note in the native-layout branch its still called testextendedlayout2). So, here's a global picture of what's in the incubator branch and what didnt make it: In: - The GtkExtendedLayout ofcourse (this is the basic API for requesting height-for-width size requests (this is all the new code that manages what sizes a widget will request in either dimension, doing deals with size groups and explicit size requests, caching the whole expensive operation and all that noise). - GtkLabel features: o The label now does height-for-width and also width-for-height when the text is rotated to 90 or 270 degrees. o The label now requests a full natural size to fit ellipsizing text unless capped by max-width-chars. (this includes rotated text in any angle). o max-width-chars / width-chars act as guides to hint at good minimum widths and max natural widths when wrapping text. - GtkBox will allocate children according to their natural sizes (the key container right now producing the overall effect of height-for-width geometry) - Mathias Hasselmann's testellipsize test which demos rotating ellipsizing label allocations. - A new test 'extendedlayoutexample' showing various interfaces using the natural layout features. Out: - GtkExtendedCell: this is the cell renderer specific api, the cell renderers already do natural sizes for ellipsize but don't yet do width-for-height or height-for-width (they also just need some basic attention I didnt have time for). - Mathias Hasselmann's testextendedlayout test which is really a great and thorough test, it needs work to bring up to speed on what to expect in terms of behaviors of GtkLabel, it also expects other stuff to pass that's just not ready yet (cell renderers etc). - GtkComboBox support depends on the cell renderer stuff so its still not ready. - GtkPlug/GtkSocket support: this is just a matter of changing the api from a natural requisition of width/height pair to a dual pass requisition of -get_height_for_width(). Would be really simple to finish these off as it just needs to be set straight to forward along the new height-for-width api. The idea here is of course that we keep native-layout branch up to date and that will be a great place to continue work on GtkTable, finish up cell renderers and incrementally introduce these new features to GTK+. About compatibility, afaics only these side effects are introduced: - Direct access to -requisition is invalid and needs to be gtk_extended_layout_get_desired_size (or at least gtk_widget_get_child_requisition). - GtkBin classes that define a custom padding must implement get_desired_width()/get_desired_height() to report them correctly along with the child values (otherwise only the base values from a size-request is used). - GtkLabel heuristics have change a bit with regards to max-width-chars and width-chars, although I doubt the impacts are going to be visibly negative. Some regrets: - I think in the end I would have preferred an enum return type for gtk_extended_layout_is_height_for_width(); it really makes no difference in practice but would make for better readable documentation. - While it was besides the point; it would be nice to take a few days; maybe include -size_allocate() in the new API and come up with a completely floating point api for GTK+ 3.0. (this was one among the countless bugzilla comments I read). And ofcourse, the whole thing is going to consume more memory to cache the multiple requisitions; and the requests are going to be slower no matter what. While there is undoubtedly room for optimization in GtkLabel, over all we are moving from a one size requisition and one
Re: Empty containers and border_width
On Fri, Apr 16, 2010 at 3:47 PM, Federico Mena Quintero feder...@novell.com wrote: Empty containers (well, I just checked GtkBox and GtkTable) will request a size of (2 * border_width) if the container is empty. Shouldn't the requisition be just 0 for such empty containers? Seems that this may automatically de-chubbify some stale .ui files that end up with all-empty slots in containers. Federico, As nobody replied; my thoughts on this are that containers of all sorts are expected to take into account their border width regardless of children, its just an expected behavior that would be painful to change (and its one guideline for another, doesnt really change much. not to mention changing that would subtly break API by changing expected outputs). And no real need to worry either; border-width is not a style property and should be setup explicitly in the interface (isn't the default value zero anyway ?). Containers that expect to be empty at times should simply be aware of their padding. Cheers, -Tristan Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATCH] Prevent the configure script to fail if CFLAGS=-Werror is specified
Hello,
this is my first patch for GTK+, I hope this is the proper place to send
it, please forgive me if I am wrong :-)
Without the patch, configure fails with this error (in config.log):
configure:23638: checking if X11/extensions/XIproto.h is needed for xReply
configure:23651: gcc -c -DGDK_PIXBUF_DISABLE_DEPRECATED -Werror -Wall
-DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES
-DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES conftest.c
5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:73: error: unused variable 'rep'
configure:23651: $? = 1
Have the possibility to specify CFLAGS=-Werror is very helpful to spot
easier other warnings.
Cheers,
Giuseppe
From 506ab703aa2d57bbe3847dc0603685f4226dac2b Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Mon, 12 Apr 2010 15:04:36 +0200
Subject: [PATCH] Prevent the configure script to fail if CFLAGS=-Werror is
specified
---
configure.in | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/configure.in b/configure.in
index d18b2f0..c8095f8 100644
--- a/configure.in
+++ b/configure.in
@@ -1408,12 +1408,14 @@ if test x$gdktarget = xx11; then
# Check for xReply
AC_MSG_CHECKING([if X11/extensions/XIproto.h is needed for xReply])
- AC_TRY_COMPILE([#include X11/Xlibint.h],
- [xReply *rep;],
+ AC_TRY_COMPILE([#include X11/Xlibint.h
+xReply *rep () {return NULL;}],
+ [rep ();],
[AC_MSG_RESULT([no])],
[AC_TRY_COMPILE([#include X11/extensions/XIproto.h
-#include X11/Xlibint.h],
- [xReply *rep;],
+#include X11/Xlibint.h
+xReply *rep () {return NULL;}],
+ [rep ();]
[AC_MSG_RESULT([yes])
AC_DEFINE([NEED_XIPROTO_H_FOR_XREPLY], 1,
[Define if X11/extensions/XIproto.h needed for
xReply])],
--
1.7.0.3
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATCH] Prevent the configure script to fail if CFLAGS=-Werror is specified
Hello,
This is my second attempt to send it...
Without the patch, configure fails with this error (in config.log):
configure:23638: checking if X11/extensions/XIproto.h is needed for xReply
configure:23651: gcc -c -DGDK_PIXBUF_DISABLE_DEPRECATED -Werror -Wall
-DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES
-DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES conftest.c
5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:73: error: unused variable 'rep'
configure:23651: $? = 1
Have the possibility to specify CFLAGS=-Werror is very helpful to spot
easier other warnings.
Cheers,
Giuseppe
From 506ab703aa2d57bbe3847dc0603685f4226dac2b Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Mon, 12 Apr 2010 15:04:36 +0200
Subject: [PATCH] Prevent the configure script to fail if CFLAGS=-Werror is
specified
---
configure.in | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/configure.in b/configure.in
index d18b2f0..c8095f8 100644
--- a/configure.in
+++ b/configure.in
@@ -1408,12 +1408,14 @@ if test x$gdktarget = xx11; then
# Check for xReply
AC_MSG_CHECKING([if X11/extensions/XIproto.h is needed for xReply])
- AC_TRY_COMPILE([#include X11/Xlibint.h],
- [xReply *rep;],
+ AC_TRY_COMPILE([#include X11/Xlibint.h
+xReply *rep () {return NULL;}],
+ [rep ();],
[AC_MSG_RESULT([no])],
[AC_TRY_COMPILE([#include X11/extensions/XIproto.h
-#include X11/Xlibint.h],
- [xReply *rep;],
+#include X11/Xlibint.h
+xReply *rep () {return NULL;}],
+ [rep ();]
[AC_MSG_RESULT([yes])
AC_DEFINE([NEED_XIPROTO_H_FOR_XREPLY], 1,
[Define if X11/extensions/XIproto.h needed for
xReply])],
--
1.7.0.3
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Extended Layout incubator branch.
Good morning, I've managed to get the base feature set of the native-layout branch working and in a usable state. By usable I mean: I've been running Glade on the extended layout branch for the past week and all of the regressions I've spotted so far have been fixed, I can also run the Gimp and gedit with no visible regressions yet (and ofcourse, the gtk-demo and testgtk as well). It should also of course essentially solve the height-for-width bug[0] and at least provide the right framework to adress the GtkExpander ellipsize bug[1] and probably a few more. I also spent some time today documenting the API which makes alot more sense now (at least to me) I've salvaged everything that is clean and usable thus far into a new 'native-layout-incubator' branch. This branch was created for the review process and potential inclusion of the whole height-for-width geometry management system and modest feature set to leverage it. Anyone interested should try compiling the incubator branch (or the native-layout branch even) and run the example in the tests directory: ./tests/extendedlayoutexample (note in the native-layout branch its still called testextendedlayout2). So, here's a global picture of what's in the incubator branch and what didnt make it: In: - The GtkExtendedLayout ofcourse (this is the basic API for requesting height-for-width size requests (this is all the new code that manages what sizes a widget will request in either dimension, doing deals with size groups and explicit size requests, caching the whole expensive operation and all that noise). - GtkLabel features: o The label now does height-for-width and also width-for-height when the text is rotated to 90 or 270 degrees. o The label now requests a full natural size to fit ellipsizing text unless capped by max-width-chars. (this includes rotated text in any angle). o max-width-chars / width-chars act as guides to hint at good minimum widths and max natural widths when wrapping text. - GtkBox will allocate children according to their natural sizes (the key container right now producing the overall effect of height-for-width geometry) - Mathias Hasselmann's testellipsize test which demos rotating ellipsizing label allocations. - A new test 'extendedlayoutexample' showing various interfaces using the natural layout features. Out: - GtkExtendedCell: this is the cell renderer specific api, the cell renderers already do natural sizes for ellipsize but don't yet do width-for-height or height-for-width (they also just need some basic attention I didnt have time for). - Mathias Hasselmann's testextendedlayout test which is really a great and thorough test, it needs work to bring up to speed on what to expect in terms of behaviors of GtkLabel, it also expects other stuff to pass that's just not ready yet (cell renderers etc). - GtkComboBox support depends on the cell renderer stuff so its still not ready. - GtkPlug/GtkSocket support: this is just a matter of changing the api from a natural requisition of width/height pair to a dual pass requisition of -get_height_for_width(). Would be really simple to finish these off as it just needs to be set straight to forward along the new height-for-width api. The idea here is of course that we keep native-layout branch up to date and that will be a great place to continue work on GtkTable, finish up cell renderers and incrementally introduce these new features to GTK+. About compatibility, afaics only these side effects are introduced: - Direct access to -requisition is invalid and needs to be gtk_extended_layout_get_desired_size (or at least gtk_widget_get_child_requisition). - GtkBin classes that define a custom padding must implement get_desired_width()/get_desired_height() to report them correctly along with the child values (otherwise only the base values from a size-request is used). - GtkLabel heuristics have change a bit with regards to max-width-chars and width-chars, although I doubt the impacts are going to be visibly negative. Some regrets: - I think in the end I would have preferred an enum return type for gtk_extended_layout_is_height_for_width(); it really makes no difference in practice but would make for better readable documentation. - While it was besides the point; it would be nice to take a few days; maybe include -size_allocate() in the new API and come up with a completely floating point api for GTK+ 3.0. (this was one among the countless bugzilla comments I read). And ofcourse, the whole thing is going to consume more memory to cache the multiple requisitions; and the requests are going to be slower no matter what. While there is undoubtedly room for optimization in GtkLabel,
Re: Empty containers and border_width
On Wed, 2010-04-21 at 05:23 -0400, Tristan Van Berkom wrote: Containers that expect to be empty at times should simply be aware of their padding. Yeah, good points. People do use empty containers (alignments and such) to add indentation for sections in configuration dialogs. So I won't change anything, just fix GtkTable's row/column spacings as described in my other mail. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Prevent the configure script to fail if CFLAGS=-Werror is specified
On Wed, Apr 21, 2010 at 3:04 PM, Giuseppe Scrivano gscriv...@gnu.org wrote: Giuseppe, This is my second attempt to send it... you should file a bug into gnome bugzilla and attach your patch there, not every developer will see it here on the mailing list. cheers! -- Gian Mario Tagliaretti GNOME Foundation member gia...@gnome.org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
