Geometry Management
I'm trying to get my head around GTK+ 3.0's new 'Height-for-width Geometry Management'. Sorry if I'm missing it in the documentation somewhere, but what exactly is the definition of a widget's natural width or height? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Geometry Management
On Sun, Sep 25, 2011 at 5:36 PM, Matthew Bucknall wrote: > I'm trying to get my head around GTK+ 3.0's new 'Height-for-width > Geometry Management'. Sorry if I'm missing it in the documentation > somewhere, but what exactly is the definition of a widget's natural > width or height? its pretty simple: you ask the widget: 1) If you have to fit into much height, how wide will you be? 2) if you have to fit into much width, how high will you be? its up to the widget to define the answers to both questions. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Geometry Management
On 25 September 2011 23:07, Paul Davis wrote: > On Sun, Sep 25, 2011 at 5:36 PM, Matthew Bucknall > wrote: >> I'm trying to get my head around GTK+ 3.0's new 'Height-for-width >> Geometry Management'. Sorry if I'm missing it in the documentation >> somewhere, but what exactly is the definition of a widget's natural >> width or height? > > its pretty simple: you ask the widget: > > 1) If you have to fit into much height, how wide will you be? > 2) if you have to fit into much width, how high will you be? > > its up to the widget to define the answers to both questions. > That seems to pertain to the gtk_widget_get_preferred_height_for_width () and gtk_widget_get_preferred_width_for_height () functions which I understand. What I'm not clear on is the meaning of the 'natural' arguments in calls to gtk_widget_get_preferred_height () and gtk_widget_get_preferred_width (). Are the natural sizes just some sort hint to containers which may result in more aesthetically pleasing layouts than just going by the minimum sizes alone? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Geometry Management
On Sun, Sep 25, 2011 at 6:20 PM, Matthew Bucknall wrote: > What I'm not clear on is the meaning of the 'natural' arguments in > calls to gtk_widget_get_preferred_height () and > gtk_widget_get_preferred_width (). > > Are the natural sizes just some sort hint to containers which may > result in more aesthetically pleasing layouts than just going by the > minimum sizes alone? i think its the corollary to the other two questions: 1) if there was no restriction on height or width, how wide would you be? 2) if there was no restriction on height or width, how high would you be? and yes, they act as hints of varying levels of "power" to a container. some containers may completely ignore the answers, or completely ignore some subset of the answers, or work very hard to find an optimal layout. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Geometry Management
On Sun, 2011-09-25 at 18:23 -0400, Paul Davis wrote: > On Sun, Sep 25, 2011 at 6:20 PM, Matthew Bucknall > wrote: > > > What I'm not clear on is the meaning of the 'natural' arguments in > > calls to gtk_widget_get_preferred_height () and > > gtk_widget_get_preferred_width (). > > > > Are the natural sizes just some sort hint to containers which may > > result in more aesthetically pleasing layouts than just going by the > > minimum sizes alone? It's a bit confusing what is the right answer for "natural_width" when implementing a widget, the accurate explanation about natural size is: the size at which a widget will cease to compete with it's siblings for space in a said container. But you could just say they are 'hints', they basically mean "at what size am I satisfied that I have enough width", it does not mean that no greater width given can be used (a wrapping label can have a natural width that is not the entire text length). Long winded story I guess I felt like writing... When allocating children of a container we always have enough space to satisfy the minimum size, after that (assuming the container is height-for-width aware) space is distributed to smaller widgets first until every sibling reaches it's natural size and then finally extra space is given to widgets who requested to 'expand'. Allocating children taking into consideration minimum and natural width allows for better management of space, simply put; more (possibly dynamic) content can appear on screen at once. Imagine a setup where you have a details box of sorts on the left and a content area on the right. Lets say that the content area is set to expand horizontally and the details box's width is limited by a translatable "title" label at the top which is set to ellipsize. In this case, the title label's full width will (by default) define the natural width of the label and consequently when resizing the application; the parent box will always try to fit the detail area with the entire title label (if possible) and leave the remainder to the content window. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 3.2.0
GTK+ 3.2.0 is now available for download at: http://download.gnome.org/sources/gtk+/3.2/ ftp://ftp.gtk.org/pub/gtk/3.2/ bce3c1a9be6afd7552c795268656d8fdd09c299765a7faaf5a76498bb82ed44c gtk +-3.2.0.tar.xz b285074ffefb4ff4364f6dd50fe68c7e85b11293e0c1dd3bdeac56052344dadb gtk +-3.2.0.tar.bz2 What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. GTK+ is the only 100% free-of-cost open source industrial-strength GUI toolkit available today. Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP), GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation of the GNOME desktop. What's new in GTK+ 3.2 == * Many improvements to the CSS theming support * Width-for-height support in many more widgets: GtkPaned, GtkMenuBar, GtkNotebook, * New experimental Wayland and HTML5 backends * GtkFileChooser and GtkAssistant have received face-lifts * The GtkFontSelection has been replaced by a new family of GtkFontChooser widgets * New widgets: GtkLockButton and GtkOVerlay For more details and lists of fixed bugs, see the announcements for the 3.1.x development releases: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00072.html http://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00031.html http://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00040.html http://mail.gnome.org/archives/gtk-devel-list/2011-July/msg2.html http://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00053.html http://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00035.html http://mail.gnome.org/archives/gtk-devel-list/2011-September/msg9.html http://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00148.html http://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00165.html Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://library.gnome.org/devel/gtk/stable/gtk-building.html Common questions: http://library.gnome.org/devel/gtk/stable/gtk-question-index.html Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks GTK+ is the product of many people. Apart from the core GTK+ team, many others also contributed to this release: Alberto Ruiz, Alejandro Piñeiro, Alexander Larsson, Alexander Saprykin, Andrea Cimitan, Andre Klapper, Arnel Borja, Arx Cruz, Bastien Nocera, Behdad Esfahbod, Benjamin Berg, Benjamin Otte, Brian Cameron, Carlos Garnacho, Chris Coulson, Christian Persch, Chun-wei Fan, Claudio Saavedra, Colin Walters, Cosimo Cecchi, Daniel Drake, Dan Winship, David King, David Zeuthen, Diego Celix, Eitan Isaacson, Federico Mena Quintero, Felix Riemann, Florian Müllner, Greg Hellings, Ignacio Casal Quinteiro, Javier Jardón, Jesse van den Kieboom, Joachim Breitner, Johan Dahlin, John Lindgren, John Palmieri, John Ralls, John Stowers, José Aliste, Juan A. Suarez Romero, Juan Pablo Ugarte, Jürg Billeter, Kalev Lember, Kazuki Iwamoto, Kjell Ahlstedt, Kristian Høgsberg, Kristian Rietveld, Lapo Calamandrei, Laszlo Pandy, Marc-André Lureau, Marek Kašík, Matt Barnes, Matthew Barnes, Micah Carrick, Michael Hutchinson, Michael Natterer, Michael Terry, Michal Suchanek, Mike Gorse, Murray Cumming, Paolo Borelli, Patrick Welche, Pavel Holejsovsky, Philip Withnall, Richard Hughes, Rico Tzschichholz, Rui Matos, Ryan Lortie, Ryo Hashimoto, Scott Moreau, Sébastien Granjoux, Stéphane Maniaci, Tristan Van Berkom, Vincent Bernat, Vincent Untz, William Jon McCann, Will Thompson, Xan Lopez, Xavier Claessens Special thanks to Alberto Ruiz for his work on GtkFontChooser September 25, 2011 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Please consider for inclusion in glib 2.30
https://bugzilla.gnome.org/show_bug.cgi?id=660095 Its small, it doesn't affect anything except Windows and it fixes an actual build problem if your environment does have dirent.h. Thank you. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
_wstat on Windows (actually stat stuff in general)
In at least gstdio.c, possibly other places (I am still looking) there is a
lot of code to use the "wide" versions of various functions like stat,
because it is assumed that the input argument is UTF-8 and the CRT doesn't
support UTF-8 directly but rather Microsoft's own multibyte character set
stuff (MBCS). In almost all cases this is cool except for 1: stat. MSDN has
this to say about _wstat:
"_wstat does not work with Windows Vista symbolic links. In these cases,
_wstat will always report a file size of 0. _stat does work correctly with
symbolic links."
So, for stat, we have to do a double conversion: first from the input UTF-8
to UTF-16, and then from UTF-16 to MBCS so that we can call stat instead of
wstat so that users don't get any nasty surprises when using g_stat() on a
symlink in Vista. *le sigh*
There is also a broader issue with stat. The size of struct stat can vary
according to what macros are defined when you include . If you
have _FILE_OFFSET_BITS=64 defined your size fields are 64-bit, otherwise
they *can* be 64-bit but are most often 32-bit. Thus, if glib was compiled
without _FILE_OFFSET_BITS defined, and an application uses g_stat() but
DOES have it defined, you're in for trouble (and the inverse is true - if
glib was compiled with _FILE_OFFSET_BITS=64 and the app wasn't, the same
hilarity ensues).
On almost all UNIX systems time_t is a signed 32-bit int thus capable of
representing time from the epoch through some time in 2038. Windows has
support for 64-bit time fields which is surprisingly forward thinking of them.
Since GLib is a "platform library" it would be extremely useful if
gstsdio.h defined a GLib version of the stat structures instead of just
doing "typedef struct stat GStatBuf". That structure can be consistently
defined, with sufficiently large data types that it will work on all
systems. Despire the coolness of Windows supporting time fields 64-bits
wide for the least amount of pain it would probably be best if the time
fields were left at 32-bits (although it would be really cool and forward
thinking if we used 64-bits), but to use 64-bit fields for all size fields,
and 32-bit fields for all others. That way gstdio.[ch] can be compiled in a
very specific way to get the information needed and then smush it into that
portable structure. Here's how I would define the GStatBuf data type:
typedef struct GStatBuf {
guint32 st_dev;
guint64 st_ino;
guint16 st_mode;
guint16 st_nlink;
guint32 st_uid;
guint32 st_gid;
guint32 st_rdev;
gint64 st_size;
gint32 st_atime;
gint32 st_mtime;
gint32 st_ctime;
} GStatBuf;
We would of course add defines for things like G_S_IFDIR, G_S_IFMT etc that
are also nice and portable (and the corresponding G_S_ISDIR type macros).
While in gstdio I'd also add the glaring-by-their-omission g_lseek,
g_fseek, and g_ftell all of which could take a gint32 as their argument or
return value.
A good case could be made for extending gtypes.h to include some primnitive
types such a gtime_t, goffs_t etc and use those but that's just syntactic
sugar really. Using the existing types would be just fine.
I'd really love to do this if no-one has any objections?
Kean
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
