Nabble - Gtk+ - Dev - General

Re: glib on Symbian

2008-09-05T13:44:01Z

sparkymat wrote:
> We are doing what you have mentioned above, i.e. defining name of global
> variables as function calls returning a pointer.

So, this limitation is *only* for the simulator, not the actual Symbian
running on mobile hardware, right? If that's the case I believe the simulator
should be fixed instead.

behdad

> For example, in gdate.c,
>
> static gboolean using_twodigit_years = FALSE;
>
> would become
>
> #if defined(__SYMBIAN32__) && defined(EMULATOR)
> PLS(using_twodigit_years,gdate, gboolean)
> #define using_twodigit_years
> (*FUNCTION_NAME(using_twodigit_years ,gdate)()
> #else
> static gboolean using_twodigit_years = FALSE;
> #endif
>
> where the PLS() macro will add the specified variable to the Process
> Local Storage, and the define will map it to a function pointer.
>
> This is repeated for all write-able static data (WSD).

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Slaving the GTK+ main loop to an external main loop

2008-09-05T06:51:14Z

On Mon, 2008-09-01 at 15:11 -0400, Owen Taylor wrote:
> One distinct problem for ports of GTK+ to other windowing systems has
> been dealing with modal operations in the windowing systems API;

[...]

> So all we have to do is do everything before the dispatch() step in
> the thread, signal the main thread do the dispatch() call, wait for
> that to complete, then continue.

I spent some time this week trying to get the idea implemented on OS X;
although I got it working OK (I've attached the patch for reference)
there were some significant bottlenecks that I wanted to write up here
in case anyone else tries this in the future.

The big problems centered around loop ownership and reentrancy -
inherently the main thread has to be the "owner" of the main loop - the
caller of g_main_context_acquire(). If the helper thread is the owner of
the main context, then you will get deadlocks if the application calls a
function like gtk_dialog_run() because the main thread is waiting for
the helper thread to process events to finish the dialog, but the helper
thread is waiting for the main thread to do the dispatch part of the
main loop.

Once the main thread is the loop owner, then you have the problem that
the main loop iteration in the helper thread is only partially in sync
with the operation of the main thread... so a lot of the assumptions
that the GLib main loop makes don't fully work; attempts to do recursive
main loop iterations in particular tend to trigger scary warnings. Also,
you have problems where GTK+ code adds an event to the event queue in
the expectation that the main thread is not blocking, but it is blocking
in the other thread; a call to g_main_context_wakeup() needs to be
added.

Efficiency is also pretty bad. You also get interactions like:

- Window is resized, and a GDK event is queued
- Main thread calls g_main_context_wakeup() to wake up the helper
thread.
- Helper thread sees the event has been queued and then sends a Cocoa
event to wake up the main thread.
- Main thread wakes up and dispatches the event

There were also some quartz specific issues: for one thing, window
resizing was my main target and it there's no easy begin/end
notifications for that; you can use CFRunLoopObserver to detect entry
and leaving the run loop, but that appears as a separate Enter/Leave
notification for every motion event, which makes things even more
inefficient since we have to keep starting and stopping the iteration
in the helper thread.

A second quartz specific problem was simply that I was trying to use the
same helper thread for poll() emulation and for iteration during modal
operations so things got pretty hairy: lots of different states in the
state machine.

During work on this approach, I realized that a more simple and
efficient approach was possible on OS X based on CFRunLoopObserver...
you could simply call the g_main_context_iteration() functions directly
at the appropriate points in the native run loop. An alternate patch
based on that approach came out quite a bit better and can be found at:

http://bugzilla.gnome.org/show_bug.cgi?id=550942

So the patch attached below, is in my opinion, a dead end as far as OS X
is concerned. I think my conclusion on the general technique is that it
is workable in situations when nothing else is possible, but shouldn't
be a first choice.

- Owen

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

main-loop-separate-thread.patch (23K) Download Attachment

Re: glib on Symbian

2008-09-05T04:02:26Z

OK, I see, I think it would be cleaner to do it like this: in gdate.c
the only change would be to have:

GLIB_STATIC (gboolean, using_twodigit_years, FALSE);

and then have the GLIB_STATIC macro defined in some suitable header:

#if defined(__SYMBIAN32__) && defined(EMULATOR)
# define GLIB_STATIC(type, name, initvalue) \
PLS(name, type) \
static type PTR_name(void) \
{ \
static type value = initvalue; \
return &value; \
}
#else
# define GLIB_STATIC(type, name, initvalue) type name = initvalue
#endif

and then have a preprocessing script that changes all occurences of
identifiers that are seen in GLIB_STATIC() macros to
(*PTR_identiifier) instead, i.e. for instance it would change all uses
of using_twodigit_years to *(PTR_using_twodigit_years) after it sees
the GLIB_STATIC (gboolean, using_twodigit_years, FALSE) in gdate.c

(This is just a quick sketch, no idea if it actually would work in
general, etc.)

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib on Symbian

2008-09-05T03:46:23Z

Please show some concrete (minimal) example... I have a hard time to
understand *exactly* what you mean.

There must be some better way around this than adding 2000 ifdefs all
around the code, which frankly doesn't sound acceptable to me. Sure,
some ifdefs can be added, but in as few places as possible. Some
clever use of the C preprocessor defining names of global variables
as function calls retuning a pointer to function-local static data
instead, or some clever preprocessing script used for Symbian
compilations, or whatever.

--tml

We are doing what you have mentioned above, i.e. defining name of global variables as function calls returning a pointer.

For example, in gdate.c,

static gboolean using_twodigit_years = FALSE;

would become

    #if defined(__SYMBIAN32__) && defined(EMULATOR)
       PLS(using_twodigit_years,gdate, gboolean)
       #define using_twodigit_years   (*FUNCTION_NAME(using_twodigit_years ,gdate)()
    #else
        static gboolean using_twodigit_years = FALSE;
    #endif

where the PLS() macro will add the specified variable to the Process Local Storage, and the define will map it to a function pointer.

This is repeated for all write-able static data (WSD).

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib on Symbian

2008-09-05T02:51:57Z

> There is one more issue that needs addressing. The Symbian OS emulator does
> not support global static data in libraries. We found a fair amount of
> global static data in the code and to work around these, we have symbian
> specific code inserted within '#ifdef SYMBIAN32' . The problem here is that
> these changes are peppered throughout the code and rack up nearly 2000 lines
> of changed code.

Please show some concrete (minimal) example... I have a hard time to
understand *exactly* what you mean.

There must be some better way around this than adding 2000 ifdefs all
around the code, which frankly doesn't sound acceptable to me. Sure,
some ifdefs can be added, but in as few places as possible. Some
clever use of the C preprocessor defining names of global variables
as function calls retuning a pointer to function-local static data
instead, or some clever preprocessing script used for Symbian
compilations, or whatever.

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib on Symbian

2008-09-04T20:49:18Z

I am a developer working for Symbian. We have ported glib to the Symbian OS and wish to contribute the changes back to the main codeline. We had talked to Tim Janik and Dave Neary regarding this and they recommended the changes be split up into smaller patches and be submitted to either of bugzilla or the mailinglist.

There is one more issue that needs addressing. The Symbian OS emulator does not support global static data in libraries. We found a fair amount of global static data in the code and to work around these, we have symbian specific code inserted within '#ifdef SYMBIAN32' . The problem here is that these changes are peppered throughout the code and rack up nearly 2000 lines of changed code. Without these changes, glib will not work on the Symbian OS emulator.

I am looking for your opinions regarding how to handle this particular changeset.

Thanks & Regards,
Ajith

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 2.14.1

2008-09-04T19:48:24Z

GTK+ 2.14.1 is now available for download at:

http://download.gnome.org/sources/gtk+/2.14/

gtk+-2.14.1.tar.bz2 md5sum: c6e66ffe92724d83391187f0af016b23
gtk+-2.14.1.tar.gz md5sum: 48003f502e916e6f004a23c6985d4432

This is a quick followup release to fix a deadlock in
pixbuf loader initialization that was introduced by a
last-minute fix before 2.14.0.

September 4, 2008
Matthias Clasen

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 2.14.0 released

2008-09-04T11:27:20Z

GTK+ 2.14.0 is now available for download at:

http://download.gnome.org/sources/gtk+/2.14/

gtk+-2.14.0.tar.bz2 md5sum: 8cd2732b4e07a490691ae3635b71d932
gtk+-2.14.0.tar.gz md5sum: 8ae7ed0c95907b5be29fc4a3c36f0499

Release notes are available at:

http://www.gtk.org/notes/gtk-2.14.0-notes.txt

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; GTK+ 2.14 will be incorporated into version
2.24 of the GNOME desktop.

What's new in GTK+ 2.14
=======================

GTK+ 2.14 adds new functionality while maintaining source and binary
compatibility with GTK+ 2.12. Highlights of new features and
improvements in GTK+ 2.14 are:

New widgets and objects

* GdkAppLaunchContext, provides startup notification with
g_app_info_launch()
* GtkMountOperation, can ask for passwords when mounting
volumes with g_volume_mount()
* GtkToolShell, an interface for containers of GtkToolItems

Noteworthy new APIs

* gtk_show_uri(), a replacement for gnome_vfs_url_show() and
gnome_url_show()
* gtk_widget_get_snapshot(), using pixmap redirection to render
snapshots of widgets

Changes in the file chooser

The file chooser uses GIO directly, loadable backends are no longer
supported. Autocompletion in the file chooser entry has been improved.

Changes in printing support

The print dialog displays printer status information. Support for
rearranging pages when printing multiple pages per sheet has been
added to the cups backend.

Accessibility support

The gail module is shipped with GTK+, GtkBuilder supports
accessibility attributes and GtkStatusIcon supports keyboard
navigation.

Internationalization support

The compose sequences understood by GTK+'s builtin input method
have been synchronized with recent X.org compose sequences, adding
a large number of new sequences. GTK+ no longer uses translations
when an application is not translated to the current locale.

gdk-pixbuf changes

* Support loading OS X icns format
* Support loading JPEG 2000 images
* Support loading and saving to GIO streams
* Use GIO for mime information

GDK changes

GDK uses Xrandr instead of Xinerama to provide more (and dynamic)
monitor information. Font configuration changes are now picked up
at runtime, without an application restart.

For more details and lists of fixed bugs, see the
announcements for the 2.13.x development releases:

http://mail.gnome.org/archives/gtk-devel-list/2008-February/msg00079.html
http://mail.gnome.org/archives/gtk-devel-list/2008-May/msg00112.html
http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00033.html
http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00158.html
http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00044.html
http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00182.html
http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00023.html
http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00153.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://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html

Common questions:

http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html
http://www.gtk.org/faq/

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

The GTK+ Team:

Jonathan Blandford, Hans Breuer, Kristian Rietveld,
Matthias Clasen, Tim Janik, Tor Lillqvist, Federico Mena Quintero,
Søren Sandmann, Manish Singh, and Owen Taylor

Special thanks to Ed Catmur and Cody Russell for fixing the
most annoying bug 56070

Thanks to everybody else who has contributed to this release:
Akira Tagoh, Alberto Ruiz, Alexander Larsson, Alex Simon,
Anders Carlsson, Andreas Köhler, Andreas Sandberg, Andre Klapper,
Andrew Cowie, Andrey Tsyvarev, Antti Kaijanmäki, Armin Burgmeier,
Attilio Fiandrotti, Baptiste Mille-Mathias, Bastien Nocera,
Behdad Esfahbod, Ben Hague, Benjamin Berg, Björn Lindqvist,
Brian Pepple, Carlos Garcia Campos, Carlos Garnacho, Chris Lord,
Christian Dywan, Christian Hammond, Christian Kellner,
Christian Neumair, Christian Persch, Chris Vine, Chris Wang,
Chris Wilson, Claudio Ciccani, Claudio Saavedra, Colin Walters,
Cosimo Cecchi, Czirkos Zoltan, Damien Carbery, Daniel Atallah,
Daniel Berrange, Danny Baumann, David Brigada, David Lambert,
David Miller, David Zeuthen, Denis Oliver Kropp, Dominic Lachowicz,
Emmanuele Bassi, Erik van Pienbroek, Erwann Chenede, Étienne Bersac,
Felix Riemann, Francesco Montorsi, Frederic Crozat,
Gian Mario Tagliaretti, Gil Forcada, Guido Berhoerster,
Guillaume Cottenceau, Herbert Valerio Riedel, Hiroyuki Ikezoe,
Hong Jen Yee, Huang Peng, Hubert Figuire, Huimin He, Ian Turner,
Jaap A. Haitsma, James Pelletier, James Sharpe, Jan Arne Petersen,
Jan Janech, Jean-Yves Lefort, Jelte van der Hoek, Jens Granseuer,
Jody Goldberg, Joe Halliwell, Joe Shaw, Johan Dahlin, Johannes Schmid,
Jonh Wendell, Josselin Mouette, Juan Manuel Palacios, Juri Pakaste,
Kazuki Iwamoto, Kevin Ryde, Kjartan Maraas, Lapo Calamandrei,
Lennart Poettering, Leonardo Ferreira Fontenelle, Liqing Huang,
LiYan Zhang, Li Yuan, Marcus Brinkmann, Marek Kašík,
Mariano Suárez-Alvarez, Marko Lindqvist, Martyn Russell,
Mathias Hasselmann, Matthew Barnes, Matthias Warkus, Matt Kraai,
Michael Emmel, Michael Hofmann, Michael Natterer, Miguel Gomez,
Mikael Hallendal, Mike Calmus, Mike Langlie, Mike Morrison,
Milan Crha, MINAMI Hirokazu, Morten Welinder, Murray Cumming,
Nathaniel Smith, Neil Roberts, Nelson Benitez, Nicolas Setton,
Olle Bergkvist, Paolo Borelli, Paul Davis, Pavel Syomin,
Pedro Villavicencio, Peter Bloomfield, Peter Johanson, Philip Van Hoof,
Phil Lello, Ray Strode, Ricardo Cruz, Richard Hult, Rich Burridge,
Roger Brown, Ross Burton, Ryan Lortie, Sadrul Habib Chowdhury,
Samuel Fogh, Sebastian Dröge, Sebastien Bacher, Sébastien Granjoux,
Simos Xenitellis, Stefan Kost, Stijn Hoop, Sven Herzberg,
Sven Neumann, Sylvain Pasche, Thomas Bleeker, Thomas Klausner,
Tim Evans, Tomas Bzatek, Tommi Komulainen, Torsten Schoenfeld,
Tristan Van Berkom, Vaclav Slavik, Wang Diancheng, William Lachance,
William Pitcock, Wolfgang Oertl, Wouter Bolsterlee, Xan Lopez,
Xavier Claessens, Yevgen Muntyan, Yuri Pimenov

September 4, 2008
Matthias Clasen

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] limit the number of extended layout features supported by GtkLabel at the same time

2008-09-04T02:58:13Z

> However, I'm actually thinking of disabling completely
> height_for_width/width_for_height for non-wrapping labels (right now
> it's accepted for elliipsizing labels), as well as disabling
> get_natural_size for wrapping labels. In the meanwhile, this patch
> makes things work properly.

Here is the patch to do that, on top of the other patch I sent (the
changes to gtk_label_style_set and
gtk_label_extended_layout_get_size_for_allocation are needed even with
this patch).

The results of testextendedlayout are okay (except that baseline
alignment does not work with or without my patch), and I also fixed
autotestextendedlayout because it failed in the current tip of the
branch, independent of my previous patch.

Paolo

2008-09-03 Paolo Bonzini <bonzini@...>

* gtk/gtklabel.c: Disable natural size layout for wrapping
labels (undoing part of the previous patch), and disable
height-for-width/width-for-height layout for non-wrapping,
ellipsizing labels.

* tests/autotestextendedlayout.c: Update to match the above.

diff --git a/gtk/gtklabel.c b/gtk/gtklabel.c
index fac4b7f..9adbc68 100644
--- a/gtk/gtklabel.c
+++ b/gtk/gtklabel.c
@@ -4367,11 +4367,12 @@ gtk_label_extended_layout_get_features (GtkExtendedLayout *layout)
GtkLabelPrivate *priv = GTK_LABEL_GET_PRIVATE (label);
GtkExtendedLayoutFeatures features;

- features =
- GTK_EXTENDED_LAYOUT_NATURAL_SIZE |
- GTK_EXTENDED_LAYOUT_BASELINES;
+ features = GTK_EXTENDED_LAYOUT_BASELINES;

- if (label->ellipsize || (label->wrap && priv->full_size))
+ if (!label->wrap)
+ features |= GTK_EXTENDED_LAYOUT_NATURAL_SIZE;
+
+ else if (priv->full_size)
{
gdouble angle = gtk_label_get_angle (label);

@@ -4416,40 +4417,24 @@ gtk_label_extended_layout_get_natural_size (GtkExtendedLayout *layout,
GtkRequisition *requisition)
{
GtkLabel *label;
- GtkLabelPrivate *priv;
gboolean ellipsize;
- gint wrap_width;
PangoLayout *tmp;

label = GTK_LABEL (layout);
- priv = GTK_LABEL_GET_PRIVATE (label);
+ g_assert (!label->wrap);
gtk_label_ensure_layout (label);

ellipsize = label->ellipsize;
label->ellipsize = PANGO_ELLIPSIZE_NONE;

- wrap_width = priv->wrap_width;
tmp = label->layout;
-
- /* See comment in gtk_label_size_request. */
-
- if (label->wrap)
- {
- g_object_ref (label->layout);
- gtk_label_clear_layout (label);
- }
- else
- {
- label->layout = pango_layout_copy (tmp);
- pango_layout_set_width (label->layout, -1);
- }
-
+ label->layout = pango_layout_copy (tmp);
+ pango_layout_set_width (label->layout, -1);
gtk_label_size_request (GTK_WIDGET (label), requisition);

g_object_unref (label->layout);
label->ellipsize = ellipsize;
label->layout = tmp;
- priv->wrap_width = wrap_width;
}

static gint
diff --git a/tests/autotestextendedlayout.c b/tests/autotestextendedlayout.c
index 6b47477..cf731fd 100644
--- a/tests/autotestextendedlayout.c
+++ b/tests/autotestextendedlayout.c
@@ -264,8 +264,6 @@ gtk_label_test_natural_size (void)
const GEnumValue *const wrap = (i >= 0 ? &wrap_class->values[i] : NULL);
const gchar *wrap_mode = (wrap ? wrap->value_nick : "none");

- gtk_label_set_line_wrap (label, NULL != wrap);
-
if (wrap)
gtk_label_set_line_wrap_mode (label, wrap->value);

@@ -311,7 +309,7 @@ gtk_label_test_extended_layout (void)

log_test (NULL != iface->get_features);
log_test (NULL != iface->get_height_for_width);
- log_test (NULL == iface->get_width_for_height);
+ log_test (NULL != iface->get_width_for_height);
log_test (NULL != iface->get_natural_size);
log_test (NULL != iface->get_baselines);

@@ -324,19 +322,22 @@ gtk_label_test_extended_layout (void)
log_test (0 != (features & GTK_EXTENDED_LAYOUT_NATURAL_SIZE));
log_test (0 != (features & GTK_EXTENDED_LAYOUT_BASELINES));

+ gtk_label_test_baselines ();
+ gtk_label_test_natural_size ();
+
gtk_label_set_line_wrap (label, TRUE);
+ gtk_label_set_full_size (label, TRUE);
features = gtk_extended_layout_get_features (layout);

log_test (0 != (features & GTK_EXTENDED_LAYOUT_HEIGHT_FOR_WIDTH));
log_test (0 == (features & GTK_EXTENDED_LAYOUT_WIDTH_FOR_HEIGHT));
- log_test (0 != (features & GTK_EXTENDED_LAYOUT_NATURAL_SIZE));
+ log_test (0 == (features & GTK_EXTENDED_LAYOUT_NATURAL_SIZE));
log_test (0 != (features & GTK_EXTENDED_LAYOUT_BASELINES));

g_object_unref (widget);

gtk_label_test_baselines ();
gtk_label_test_height_for_width ();
- gtk_label_test_natural_size ();
}

static void
@@ -397,11 +398,12 @@ gtk_bin_test_extended_layout (void)
log_test (0 != (features & GTK_EXTENDED_LAYOUT_BASELINES));

gtk_label_set_line_wrap (GTK_LABEL (label), TRUE);
+ gtk_label_set_full_size (GTK_LABEL (label), TRUE);
features = gtk_extended_layout_get_features (layout);

log_test (0 != (features & GTK_EXTENDED_LAYOUT_HEIGHT_FOR_WIDTH));
log_test (0 == (features & GTK_EXTENDED_LAYOUT_WIDTH_FOR_HEIGHT));
- log_test (0 != (features & GTK_EXTENDED_LAYOUT_NATURAL_SIZE));
+ log_test (0 == (features & GTK_EXTENDED_LAYOUT_NATURAL_SIZE));
log_test (0 != (features & GTK_EXTENDED_LAYOUT_BASELINES));

/* verify baseline propagation */

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[PATCH] Add extended layout support for GtkViewport

2008-09-04T00:56:35Z

This patch adds extended layout support for GtkViewport. While natural
size support is easy (I would say natural...), adding
height-for-width/width-for-height support requires a new property. The
property, however, is useful even without extended layout support.

The idea is that right now the viewport will never give an allocation to
the child that is narrower than the requisition. However, it can be
useful to force the viewport to have only the vertical scrollbar (or
dually the horizontal scrollbar). This is a great application of
height-for-width/width-for-height, because these extended layout hooks
are just what is needed to get the range of the single visible scrollbar.

The patch implements this and adds a test (which won't work unless the
GtkLabel patch is applied).

With these two patches, I *guess* that extended layout branch suits my
needs. I might need to implement GtkExtendedLayout on GtkExpander, and
that's it.

Also, the "flow" behavior could indeed be implemented on GtkHBox with a
"wrap" property; I started working on a patch but it is more complicated
than I'd like for various reasons:

1) getting the algorithm right is already a mess;

2) to do it properly, it should be done in GtkVBox too (laying out in
multiple columns when you reach the bottom of the allocation); I don't
need this so I don't have very much the incentive;

3) then, does this mean that I need a new abstract class between GtkBox
and Gtk{H,V}Box? Or that I need to implement the new behavior in the
two button box classes too? This also reduces my willingness to do this.

4) Thinking more about it, it actually seems to me that the "flow"
concept is most similar to a GtkHButtonBox with left-edge packing, more
than to a GtkHBox. So I'm a bit lost about where to implement it. I'll
probably make my own container when time comes.

(Of course, I cannot really rely on something that is on a branch, so
I'll go on with my GtkManagedLayout for a while. However, I'll eagerly
wait for GTK+ 2.16 so that I can get rid of it).

Paolo

2008-09-03 Paolo Bonzini <bonzini@...>

* gtk/gtk.symbols: Add new symbols for GtkViewportConstraint and
its usage in gtk_viewport.
* gtk/gtkenums.h: Add GtkViewportConstraint.
* gtk/gtkviewport.h: Add a new GtkViewportConstraint field and
its accessors. Turn the existing shadow_type field into a bitfield.
* gtk/gtkviewport.c: Add the corresponding property; use
extended layout info.

* tests/testextlayoutviewport.c: New.
* tests/Makefile.am: Add rules for it.
---
gtk/gtk.symbols | 3 +
gtk/gtkenums.h | 8 +++
gtk/gtkviewport.c | 115 +++++++++++++++++++++++++++++++++++++++--
gtk/gtkviewport.h | 31 ++++++-----
tests/Makefile.am | 7 +++
tests/testextlayoutviewport.c | 80 ++++++++++++++++++++++++++++
7 files changed, 236 insertions(+), 18 deletions(-)
create mode 100644 tests/testextlayoutviewport.c

diff --git a/gtk/gtk.symbols b/gtk/gtk.symbols
index 842148a..dc9f6a5 100644
--- a/gtk/gtk.symbols
+++ b/gtk/gtk.symbols
@@ -358,6 +358,7 @@ gtk_icon_theme_error_get_type G_GNUC_CONST
gtk_toolbar_child_type_get_type G_GNUC_CONST
gtk_toolbar_space_style_get_type G_GNUC_CONST
gtk_toolbar_style_get_type G_GNUC_CONST
+gtk_viewport_constraint_get_type G_GNUC_CONST
#endif
#endif

@@ -4553,11 +4554,13 @@ gtk_vbutton_box_new
#if IN_FILE(__GTK_VIEWPORT_C__)
gtk_viewport_get_hadjustment
gtk_viewport_get_shadow_type
+gtk_viewport_get_size_constraint
gtk_viewport_get_type G_GNUC_CONST
gtk_viewport_get_vadjustment
gtk_viewport_new
gtk_viewport_set_hadjustment
gtk_viewport_set_shadow_type
+gtk_viewport_set_size_constraint
gtk_viewport_set_vadjustment
#endif
#endif
diff --git a/gtk/gtkenums.h b/gtk/gtkenums.h
index eeb3ac7..c8cde2a 100644
--- a/gtk/gtkenums.h
+++ b/gtk/gtkenums.h
@@ -413,6 +413,14 @@ typedef enum
GTK_UPDATE_DELAYED
} GtkUpdateType;

+/* Viewport flags to constrain width or height */
+typedef enum
+{
+ GTK_VIEWPORT_CONSTRAIN_NONE,
+ GTK_VIEWPORT_CONSTRAIN_WIDTH,
+ GTK_VIEWPORT_CONSTRAIN_HEIGHT
+} GtkViewportConstraint;
+
/* Generic visibility flags */
typedef enum
{
diff --git a/gtk/gtkviewport.c b/gtk/gtkviewport.c
index 114415b..c504f33 100644
--- a/gtk/gtkviewport.c
+++ b/gtk/gtkviewport.c
@@ -28,6 +28,7 @@
#include "gtkviewport.h"
#include "gtkintl.h"
#include "gtkmarshalers.h"
+#include "gtkextendedlayout.h"
#include "gtkprivate.h"
#include "gtkalias.h"

@@ -35,7 +36,8 @@ enum {
PROP_0,
PROP_HADJUSTMENT,
PROP_VADJUSTMENT,
- PROP_SHADOW_TYPE
+ PROP_SHADOW_TYPE,
+ PROP_SIZE_CONSTRAINT
};

@@ -125,6 +127,15 @@ gtk_viewport_class_init (GtkViewportClass *class)
GTK_SHADOW_IN,
GTK_PARAM_READWRITE));

+ g_object_class_install_property (gobject_class,
+ PROP_SIZE_CONSTRAINT,
+ g_param_spec_enum ("size-constraint",
+ P_("Size constraint"),
+ P_("Determines whether the viewport constrains the width or height of its child"),
+ GTK_TYPE_VIEWPORT_CONSTRAINT,
+ GTK_VIEWPORT_CONSTRAIN_NONE,
+ GTK_PARAM_READWRITE));
+
widget_class->set_scroll_adjustments_signal =
g_signal_new (I_("set_scroll_adjustments"),
G_OBJECT_CLASS_TYPE (gobject_class),
@@ -158,6 +169,9 @@ gtk_viewport_set_property (GObject *object,
case PROP_SHADOW_TYPE:
gtk_viewport_set_shadow_type (viewport, g_value_get_enum (value));
break;
+ case PROP_SIZE_CONSTRAINT:
+ gtk_viewport_set_size_constraint (viewport, g_value_get_enum (value));
+ break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -185,6 +199,9 @@ gtk_viewport_get_property (GObject *object,
case PROP_SHADOW_TYPE:
g_value_set_enum (value, viewport->shadow_type);
break;
+ case PROP_SIZE_CONSTRAINT:
+ g_value_set_enum (value, viewport->size_constraint);
+ break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -200,6 +217,8 @@ gtk_viewport_init (GtkViewport *viewport)
gtk_container_set_resize_mode (GTK_CONTAINER (viewport), GTK_RESIZE_QUEUE);

viewport->shadow_type = GTK_SHADOW_IN;
+ viewport->size_constraint = GTK_VIEWPORT_CONSTRAIN_NONE;
+
viewport->view_window = NULL;
viewport->bin_window = NULL;
viewport->hadjustment = NULL;
@@ -348,6 +367,50 @@ viewport_reclamp_adjustment (GtkAdjustment *adjustment,
}

static void
+viewport_child_size_request (GtkViewport *viewport,
+ GtkWidget *child,
+ GtkRequisition *requisition,
+ GtkChildSizeRequest size_request_func)
+{
+ GtkExtendedLayoutFeatures features = 0;
+ gboolean width_for_height;
+ gboolean height_for_width;
+
+ if (GTK_IS_EXTENDED_LAYOUT (child))
+ features = gtk_extended_layout_get_features ((GtkExtendedLayout*) child);
+
+ width_for_height = (viewport->size_constraint == GTK_VIEWPORT_CONSTRAIN_HEIGHT &&
+ (features & GTK_EXTENDED_LAYOUT_WIDTH_FOR_HEIGHT));
+ height_for_width = (viewport->size_constraint == GTK_VIEWPORT_CONSTRAIN_WIDTH &&
+ (features & GTK_EXTENDED_LAYOUT_HEIGHT_FOR_WIDTH));
+
+ if (height_for_width || width_for_height)
+ {
+ GtkAllocation view_allocation;
+ viewport_get_view_allocation (viewport, &view_allocation);
+ if (height_for_width)
+ {
+ requisition->width = view_allocation.width;
+ requisition->height = gtk_extended_layout_get_height_for_width (
+ (GtkExtendedLayout*) child, view_allocation.width);
+ }
+
+ else
+ {
+ requisition->width = gtk_extended_layout_get_width_for_height (
+ (GtkExtendedLayout*) child, view_allocation.height);
+ requisition->height = view_allocation.height;
+ }
+ }
+
+ else if (features & GTK_EXTENDED_LAYOUT_NATURAL_SIZE)
+ gtk_extended_layout_get_natural_size ((GtkExtendedLayout*) child, requisition);
+
+ else
+ size_request_func (child, requisition, (GtkWidget *) viewport);
+}
+
+static void
viewport_set_hadjustment_values (GtkViewport *viewport,
gboolean *value_changed)
{
@@ -373,7 +436,8 @@ viewport_set_hadjustment_values (GtkViewport *viewport,
{
GtkRequisition child_requisition;

- gtk_widget_get_child_requisition (bin->child, &child_requisition);
+ viewport_child_size_request (viewport, bin->child, &child_requisition,
+ (GtkChildSizeRequest) gtk_widget_get_child_requisition);
hadjustment->upper = MAX (child_requisition.width, view_allocation.width);
}
else
@@ -410,7 +474,8 @@ viewport_set_vadjustment_values (GtkViewport *viewport,
{
GtkRequisition child_requisition;

- gtk_widget_get_child_requisition (bin->child, &child_requisition);
+ viewport_child_size_request (viewport, bin->child, &child_requisition,
+ (GtkChildSizeRequest) gtk_widget_get_child_requisition);
vadjustment->upper = MAX (child_requisition.height, view_allocation.height);
}
else
@@ -547,6 +612,45 @@ gtk_viewport_get_shadow_type (GtkViewport *viewport)
return viewport->shadow_type;
}

+
+/**
+ * gtk_viewport_set_size_constraint:
+ * @viewport: a #GtkViewport.
+ * @type: the new size constraint.
+ *
+ * Sets the size constraint of the viewport.
+ **/
+void
+gtk_viewport_set_size_constraint (GtkViewport *viewport,
+ GtkViewportConstraint type)
+{
+ g_return_if_fail (GTK_IS_VIEWPORT (viewport));
+
+ if ((GtkViewportConstraint) viewport->size_constraint != type)
+ {
+ viewport->size_constraint = type;
+ gtk_widget_queue_resize (GTK_WIDGET (viewport));
+ g_object_notify (G_OBJECT (viewport), "size-constraint");
+ }
+}
+
+/**
+ * gtk_viewport_get_size_constraint:
+ * @viewport: a #GtkViewport
+ *
+ * Gets the shadow type of the #GtkViewport. See
+ * gtk_viewport_set_size_constraint().
+
+ * Return value: the size constraint
+ **/
+GtkViewportConstraint
+gtk_viewport_get_size_constraint (GtkViewport *viewport)
+{
+ g_return_val_if_fail (GTK_IS_VIEWPORT (viewport), GTK_VIEWPORT_CONSTRAIN_NONE);
+
+ return viewport->size_constraint;
+}
+
static void
gtk_viewport_realize (GtkWidget *widget)
{
@@ -720,7 +824,10 @@ gtk_viewport_size_request (GtkWidget *widget,

if (bin->child && GTK_WIDGET_VISIBLE (bin->child))
{
- gtk_widget_size_request (bin->child, &child_requisition);
+ viewport_child_size_request (GTK_VIEWPORT (widget), bin->child,
+ &child_requisition,
+ (GtkChildSizeRequest) gtk_widget_size_request);
+
requisition->width += child_requisition.width;
requisition->height += child_requisition.height;
}
diff --git a/gtk/gtkviewport.h b/gtk/gtkviewport.h
index 8b64f17..b07382a 100644
--- a/gtk/gtkviewport.h
+++ b/gtk/gtkviewport.h
@@ -51,7 +51,9 @@ struct _GtkViewport
{
GtkBin bin;

- GtkShadowType shadow_type;
+ guint shadow_type : 3;
+ guint size_constraint : 2;
+
GdkWindow *view_window;
GdkWindow *bin_window;
GtkAdjustment *hadjustment;
@@ -68,18 +70,21 @@ struct _GtkViewportClass
};

-GType gtk_viewport_get_type (void) G_GNUC_CONST;
-GtkWidget* gtk_viewport_new (GtkAdjustment *hadjustment,
- GtkAdjustment *vadjustment);
-GtkAdjustment* gtk_viewport_get_hadjustment (GtkViewport *viewport);
-GtkAdjustment* gtk_viewport_get_vadjustment (GtkViewport *viewport);
-void gtk_viewport_set_hadjustment (GtkViewport *viewport,
- GtkAdjustment *adjustment);
-void gtk_viewport_set_vadjustment (GtkViewport *viewport,
- GtkAdjustment *adjustment);
-void gtk_viewport_set_shadow_type (GtkViewport *viewport,
- GtkShadowType type);
-GtkShadowType gtk_viewport_get_shadow_type (GtkViewport *viewport);
+GType gtk_viewport_get_type (void) G_GNUC_CONST;
+GtkWidget* gtk_viewport_new (GtkAdjustment *hadjustment,
+ GtkAdjustment *vadjustment);
+GtkAdjustment* gtk_viewport_get_hadjustment (GtkViewport *viewport);
+GtkAdjustment* gtk_viewport_get_vadjustment (GtkViewport *viewport);
+void gtk_viewport_set_hadjustment (GtkViewport *viewport,
+ GtkAdjustment *adjustment);
+void gtk_viewport_set_vadjustment (GtkViewport *viewport,
+ GtkAdjustment *adjustment);
+void gtk_viewport_set_shadow_type (GtkViewport *viewport,
+ GtkShadowType type);
+GtkShadowType gtk_viewport_get_shadow_type (GtkViewport *viewport);
+void gtk_viewport_set_size_constraint (GtkViewport *viewport,
+ GtkViewportConstraint type);
+GtkViewportConstraint gtk_viewport_get_size_constraint (GtkViewport *viewport);

G_END_DECLS
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 99c19e6..1338dd8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -45,6 +45,7 @@ noinst_PROGRAMS = \
testellipsise \
testentrycompletion \
testextendedlayout \
+ testextlayoutviewport \
testfilechooser \
testfilechooserbutton \
testgtk \
@@ -111,6 +112,7 @@ testdnd_DEPENDENCIES = $(TEST_DEPS)
testellipsise_DEPENDENCIES = $(TEST_DEPS)
testentrycompletion_DEPENDENCIES = $(TEST_DEPS)
testextendedlayout_DEPENDENCIES = $(TEST_DEPS)
+testextlayoutviewport_DEPENDENCIES = $(TEST_DEPS)
testfilechooser_DEPENDENCIES = $(TEST_DEPS)
testfilechooserbutton_DEPENDENCIES = $(TEST_DEPS)
testgtk_DEPENDENCIES = $(TEST_DEPS)
@@ -167,6 +169,7 @@ testdnd_LDADD = $(LDADDS)
testellipsise_LDADD = $(LDADDS)
testentrycompletion_LDADD = $(LDADDS)
testextendedlayout_LDADD = $(LDADDS)
+testextlayoutviewport_LDADD = $(LDADDS)
testfilechooser_LDADD = $(LDADDS)
testfilechooserbutton_LDADD = $(LDADDS)
testgtk_LDADD = $(LDADDS)
@@ -230,6 +234,9 @@ testentrycompletion_SOURCES = \
testextendedlayout_SOURCES = \
testextendedlayout.c

+testextlayoutviewport_SOURCES = \
+ testextlayoutviewport.c
+
testfilechooser_SOURCES = \
prop-editor.c \
testfilechooser.c
diff --git a/tests/testextlayoutviewport.c b/tests/testextlayoutviewport.c
new file mode 100644
index 0000000..724e816
--- /dev/null
+++ b/tests/testextlayoutviewport.c
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2008 Free Software Foundation, Inc.
+ * Author: Paolo Bonzini <bonzini@...>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * version 2.1 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include <gtk/gtk.h>
+
+static void
+option_cb (GtkToggleButton *option,
+ GtkWidget *viewport)
+{
+ gboolean active = gtk_toggle_button_get_active (option);
+
+ gtk_viewport_set_size_constraint (GTK_VIEWPORT (viewport),
+ active ? GTK_VIEWPORT_CONSTRAIN_HEIGHT
+ : GTK_VIEWPORT_CONSTRAIN_WIDTH);
+
+ gtk_label_set_angle (GTK_LABEL (gtk_bin_get_child (GTK_BIN (viewport))),
+ active ? 90 : 0);
+}
+
+int
+main (int argc,
+ char **argv)
+{
+ GtkWidget *window;
+ GtkWidget *scrolled_window, *viewport, *label, *vbox, *option;
+
+ gtk_init (&argc, &argv);
+
+ window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
+ g_signal_connect (G_OBJECT (window), "delete-event",
+ G_CALLBACK (gtk_main_quit), NULL);
+
+ vbox = gtk_vbox_new (FALSE, 4);
+ gtk_container_add (GTK_CONTAINER (window), vbox);
+
+ scrolled_window = gtk_scrolled_window_new (NULL, NULL);
+ gtk_box_pack_start (GTK_BOX (vbox), scrolled_window, TRUE, TRUE, 0);
+
+ viewport = gtk_viewport_new (NULL, NULL);
+ gtk_viewport_set_size_constraint (GTK_VIEWPORT (viewport),
+ GTK_VIEWPORT_CONSTRAIN_WIDTH);
+ gtk_container_add (GTK_CONTAINER (scrolled_window), viewport);
+
+#define STR "This is a test %# This is a test %@# This is a test %@#$ "
+ label = gtk_label_new (STR STR STR STR STR STR STR STR STR STR STR STR STR
+ STR STR STR STR STR STR STR STR STR STR STR STR STR
+ STR STR STR STR STR STR STR STR STR STR STR STR STR
+ STR STR STR STR STR STR STR STR STR STR STR STR STR);
+
+ gtk_label_set_line_wrap (GTK_LABEL (label), TRUE);
+ gtk_label_set_full_size (GTK_LABEL (label), TRUE);
+ gtk_misc_set_alignment (&(GTK_LABEL (label)->misc), 0.0, 0.0);
+ gtk_container_add (GTK_CONTAINER (viewport), label);
+
+ option = gtk_check_button_new_with_label ("Horizontal scrollbar");
+ g_signal_connect (G_OBJECT (option), "toggled", G_CALLBACK (option_cb), viewport);
+
+ gtk_box_pack_end (GTK_BOX (vbox), option, FALSE, FALSE, 0);
+
+ gtk_widget_show_all (window);
+ gtk_main ();
+ return 0;
+}
--
1.5.5

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[PATCH] Fix a number of GtkLabel extended layout issues

2008-09-04T00:44:35Z

This is my first patch, so sorry if I get the submission process wrong.
This patch is meant for extended-layout branch, which hasn't been
merged in a year.

It fixes a number of issues with GtkLabel's extended layout support
which are uncovered by my next patch:

1) the height_for_width/width_for_height implementations worked by
computing the height in a separate PangoLayout object. However, they
did not record the desired wrapping width anywhere. This patch fixes it
by recording it in GtkLabelPrivate.

A side issue is that layout could be done before realizing. Then, upon
realizing, gtk_label_style_set is called and it invalidates the wrapping
with. This patch fixes it by not invalidating the wrapping width if it
was set by height_for_width/width_for_height.

2) For wrapping labels, gtk_label_extended_layout_get_natural_size was
destroying the wrapping width set by height_for_width/width_for_height.
This happened because it uses gtk_label_size_request which in turn
clears the layout in the case of a wrapping label.

This patch fixes it by preserving priv->wrap_width around
get_natural_size. I also modified a little the code to make it more
explicit that gtk_label_size_request computes a fresh layout for
wrapping labels.

However, I'm actually thinking of disabling completely
height_for_width/width_for_height for non-wrapping labels (right now
it's accepted for elliipsizing labels), as well as disabling
get_natural_size for wrapping labels. In the meanwhile, this patch
makes things work properly.

Ok? (I obviously require someone to commit it for me if accepted).

Paolo

2008-09-04 Paolo Bonzini <bonzini@...>

* gtk/gtklabel.c: Set priv->wrap_width in the extended-layout
height_for_width code. Preserve it in get_natural_size
because when label->wrap is set, gtk_label_size_request will
invalidate the layout and hence modify priv->wrap_width; for
the same reason, don't bother setting the layout's width to -1
if the label is wrapping. Add priv->wrap_at_container_size
so that changing the style (e.g. upon realization) does not
invalidate the layout.
---
ChangeLog.gtk-extended-layout | 11 +++++++++
gtk/gtklabel.c | 48 ++++++++++++++++++++++++++++++++++------
2 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/gtk/gtklabel.c b/gtk/gtklabel.c
index 2082d6a..fac4b7f 100644
--- a/gtk/gtklabel.c
+++ b/gtk/gtklabel.c
@@ -60,7 +60,9 @@ typedef struct
gint width_chars;
gint max_width_chars;
gint baseline_offset;
- gboolean full_size;
+
+ guint full_size : 1;
+ guint wrap_at_container_size : 1;
}
GtkLabelPrivate;

@@ -826,6 +828,8 @@ gtk_label_init (GtkLabel *label)
priv->width_chars = -1;
priv->max_width_chars = -1;
priv->wrap_width = -1;
+ priv->wrap_at_container_size = FALSE;
+
label->label = NULL;

label->jtype = GTK_JUSTIFY_LEFT;
@@ -1987,6 +1991,7 @@ gtk_label_invalidate_wrap_width (GtkLabel *label)
priv = GTK_LABEL_GET_PRIVATE (label);

priv->wrap_width = -1;
+ priv->wrap_at_container_size = FALSE;
}

static gint
@@ -2366,6 +2371,7 @@ gtk_label_style_set (GtkWidget *widget,
GtkStyle *previous_style)
{
GtkLabel *label;
+ GtkLabelPrivate *priv;

g_return_if_fail (GTK_IS_LABEL (widget));

@@ -2373,7 +2379,10 @@ gtk_label_style_set (GtkWidget *widget,

/* We have to clear the layout, fonts etc. may have changed */
gtk_label_clear_layout (label);
- gtk_label_invalidate_wrap_width (label);
+
+ priv = GTK_LABEL_GET_PRIVATE (label);
+ if (!priv->wrap_at_container_size)
+ gtk_label_invalidate_wrap_width (label);
}

static void
@@ -4379,19 +4388,26 @@ static gint
gtk_label_extended_layout_get_size_for_allocation (GtkExtendedLayout *layout,
gint size)
{
- GtkLabel *label = GTK_LABEL (layout);
- gdouble angle = gtk_label_get_angle (label);
+ GtkLabel *label;
+ GtkLabelPrivate *priv;
+ gdouble angle;
PangoLayout *tmp;

- // this test is slightly more tolerant than the get_features test
+ label = GTK_LABEL (layout);
+ priv = GTK_LABEL_GET_PRIVATE (label);
+
+ /* This test is valid for both width_for_height, and height_for_width. */
+ angle = gtk_label_get_angle (label);
g_assert (0 == (((gint)angle) % 90));

gtk_label_ensure_layout (label);
tmp = pango_layout_copy (label->layout);
pango_layout_set_width (tmp, PANGO_SCALE * size);
+ priv->wrap_width = PANGO_SCALE * size;
+ priv->wrap_at_container_size = TRUE;
+
pango_layout_get_pixel_size (tmp, NULL, &size);
g_object_unref (tmp);
-
return size;
}

@@ -4400,24 +4416,40 @@ gtk_label_extended_layout_get_natural_size (GtkExtendedLayout *layout,
GtkRequisition *requisition)
{
GtkLabel *label;
+ GtkLabelPrivate *priv;
gboolean ellipsize;
+ gint wrap_width;
PangoLayout *tmp;

label = GTK_LABEL (layout);
+ priv = GTK_LABEL_GET_PRIVATE (label);
gtk_label_ensure_layout (label);

ellipsize = label->ellipsize;
label->ellipsize = PANGO_ELLIPSIZE_NONE;

+ wrap_width = priv->wrap_width;
tmp = label->layout;
- label->layout = pango_layout_copy (tmp);

- pango_layout_set_width (label->layout, -1);
+ /* See comment in gtk_label_size_request. */
+
+ if (label->wrap)
+ {
+ g_object_ref (label->layout);
+ gtk_label_clear_layout (label);
+ }
+ else
+ {
+ label->layout = pango_layout_copy (tmp);
+ pango_layout_set_width (label->layout, -1);
+ }
+
gtk_label_size_request (GTK_WIDGET (label), requisition);

g_object_unref (label->layout);
label->ellipsize = ellipsize;
label->layout = tmp;
+ priv->wrap_width = wrap_width;
}

static gint
--
1.5.5

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO and sockets

2008-09-03T19:29:22Z

Felipe Contreras wrote:
> How should applications use sockets with GIO?
>
> I'm interested in hostname resolution, and socket handling. If
> possible also proxy handling.

There isn't yet a good story here. See
http://bugzilla.gnome.org/show_bug.cgi?id=515973 and
http://bugzilla.gnome.org/show_bug.cgi?id=548466.

One possibility that's available now is to use SoupAddress and
SoupSocket from libsoup, and just ignore the HTTP parts of the library.
This is what the gvfs ftp backend does (although gvfs already depended
on libsoup anyway, so it was an easy decision to make there).

-- Dan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GIO and sockets

2008-09-03T16:04:43Z

Hi,

How should applications use sockets with GIO?

I'm interested in hostname resolution, and socket handling. If
possible also proxy handling.

Any pointers?

--
Felipe Contreras
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_format_file_size_for_display()

2008-09-03T08:29:29Z

Am Mittwoch, den 19.12.2007, 08:52 +0100 schrieb Sven Neumann:

> Hi,
>
> On Tue, 2007-12-18 at 17:14 -0600, Federico Mena Quintero wrote:
>
> > > char *g_format_file_size_for_display (goffset size);
> > >
> > > Ideally this one needs to take another parameter indicating
> whether you
> > > want 1kb = 1000 bytes or 1kb = 1024 bytes.
> >
> > No, because then you'll have applications using either, and then
> someone
> > will want to make them consistent and we'll get an option in the
> control
> > center an an XSETTING, which is yet another thing we'll have to port
> > over when moving from GConf to DConf, and it's just a big fat mess.

The issue seems to be a constant source of conflict, so why shouldn't we
add another preference? The dispute under

http://bugzilla.gnome.org/show_bug.cgi?id=550100

proofs it. An environment variable would be enough, and if it was
outside the GLib name space it could even be used by console
applications (like ls).

> Yes, because this is a choice that the application developer needs to
> make, not the user. So this is never going to become am option in the
> control center or an XSETTING. We just need to make sure that the API
> docs give the application developer the information they need to make
> the right choice.

I'm not sure why application developers may want to enforce this
decision. Maybe you could give an example where it is important?

I tend to call it a cultural decision, i.e. something like a time format
or measurement units. Maybe it should be put into a LC_* environment
variable (cf. man locale)? That would at least make sense if it directly
depends on the country or origin of the user, rather than being “just” a
matter of taste.

best regards,
Christian Neumair

--
Christian Neumair <cneumair@...>

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Theming API Hackfest

2008-09-03T07:32:07Z

On Wed, Sep 3, 2008 at 1:25 PM, Alberto Ruiz <aruiz@...> wrote:

[...]

>> Thinking again, most of the detail strings are actually redundant if
>> the engine is allowed to know what kind of widget is drawn.
>
> No, they are not always redundant, and the engine is allowed actually.

I did not say /all/ detail strings are redundant, but if the redundant
ones were removed it might be easier to find a solution avoiding the
quirks of a string API for the remaining ones.

Also I thought this whole thread was about theming in gtk3, for which
it was proposed that direct access to widgets should be revoked. In
gtk2 it's a different story, as we all know ...

> That approach (which is quite used), suddenly ties engines to
> implementation details of widgets, denying developers to change those
> implementations since the theming API is a public interface that
> people consume to make third party engines.
>
> Now, the idea discussed is to solve that by allowing widgets to give
> more information without allowing engines to crawl up over the
> widget's parents and stuff like that.

My point is that permitting to traverse the widget tree allows for
simpler and more generic code in gtk proper. gtk_widget_get_parent()
is already there, nothing new required. See below for details.

[...]

> It is actually a quite valuable work that people start playing with
> more usable engines for artists and i'm pretty sure as soon the idea
> progress you would be able to give us a quite valuable feedback.
>
>> Generally, instead of passing more context information to the engine
>> as it is being discussed, I'd rather provide hooks to the style
>> matching subsystem for widget implementers and look mimicking. This is
>> also the approach taken in the CSS engine.
>
> You mean hooks as in "widget: If I match this style matching
> expression I send this event" or something like that?
>
> Could you elaborate a little bit on how this could be implemented and
> how much effort for a widget implementer would take to do it properly?

The CSS engine fills a vtable, so the selection engine can traverse
the widget hierarchy without actually knowing anything about widgets.
Look for `ccd_node_class_t' in the file linked below. Lookalike
toolkits could fill the vtable with their own functions, thus being
able to fake entire widget hierarchies without creating any gtk widget
offscreen to have it drawn correctly.

http://bzr-playground.gnome.org/~robsta/gtk-css-engine/annotate/54?file_id=ccdnode.h-20080812073847-d210lox1qul689g2-44
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Theming API Hackfest

2008-09-03T04:25:46Z

2008/9/3 Robert Staudinger <robert.staudinger@...>:

> On Fri, Aug 29, 2008 at 6:13 PM, Benjamin Berg
> <benjamin@...> wrote:
>
> [...]
>
>>> Here's what I learned so far:
>>> - The biggest issue is the impedance mismatch between configuring
>>> widget style properties in gtkrc while engines are built around
>>> drawing primitives.
>>
>> Not quite sure what you mean here exactly.
>
> Two issues:
>
> (1) The gtk/engine interface allows for implicit styling by the
> engine. It is possible to write a fancy engine that just uses a 3 line
> boilerplate gtkrc loading the engine library. Of course this breaks
> toolkits that try to look like gtk using gtk_rc_get_style_by_paths().
>
> (2) Gtkrc talks about widgets but engines draw primitives. E.g. a
> GtkNotebook is drawn using "box_gap" and "extender" primitives.
> However, there is no vocabulary in gtkrc to configure primitives.
>
> [...] (There are of course dusty corners)
>
>>> - Detail strings are not the problem they're sometimes made to be.
>>
>> Detail strings are part of the problem. I see two important flaws with
>> the current detail strings. The first one is that they are fixed and
>> cannot be extended easily because of API compatibility. The second one
>> is that there are a lot of inconsistencies in their naming.
>> As an example for this look at the different style properties that only
>> exists to add more information to detail strings. Or look at the two
>> scrollbars and scales. One calls the slider "[hv]scale" the other
>> "slider". And guess what? The scrollbar calls the stepper buttons
>> "[hv]scrollbar".
>>
>> Both of these make it harder to create good themes. One needs to shift
>> trough a lot of style properties and learn the different quirks of
>> widgets -- often by reading the GTK+ source code.
>
> Thinking again, most of the detail strings are actually redundant if
> the engine is allowed to know what kind of widget is drawn.

No, they are not always redundant, and the engine is allowed actually.
That approach (which is quite used), suddenly ties engines to
implementation details of widgets, denying developers to change those
implementations since the theming API is a public interface that
people consume to make third party engines.

Now, the idea discussed is to solve that by allowing widgets to give
more information without allowing engines to crawl up over the
widget's parents and stuff like that.

> I did not mean to say that there are great engines out there or that
> they weren't a lot of work, just that the internal gtk/engine
> interface is way more powerful that what most engines expose.

Powerful in this case is an enemy of maintenable code I'm afraid.

> To sum up, here is what I'm prototyping:
> - Use CSS vocabulary to match all widgets and primitives.
> - Only what is specified in CSS is drawn, nothing is implicit or
> special-cased inside the engine.
> - Feed back gtkrc snippets created from CSS to support
> gtk_rc_get_style_by_paths() [future].

It is actually a quite valuable work that people start playing with
more usable engines for artists and i'm pretty sure as soon the idea
progress you would be able to give us a quite valuable feedback.

> Generally, instead of passing more context information to the engine
> as it is being discussed, I'd rather provide hooks to the style
> matching subsystem for widget implementers and look mimicking. This is
> also the approach taken in the CSS engine.

You mean hooks as in "widget: If I match this style matching
expression I send this event" or something like that?

Could you elaborate a little bit on how this could be implemented and
how much effort for a widget implementer would take to do it properly?

--
Cheers,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Theming API Hackfest

2008-09-03T04:01:46Z

On Fri, Aug 29, 2008 at 6:13 PM, Benjamin Berg
<benjamin@...> wrote:

[...]

>> Here's what I learned so far:
>> - The biggest issue is the impedance mismatch between configuring
>> widget style properties in gtkrc while engines are built around
>> drawing primitives.
>
> Not quite sure what you mean here exactly.

Two issues:

(1) The gtk/engine interface allows for implicit styling by the
engine. It is possible to write a fancy engine that just uses a 3 line
boilerplate gtkrc loading the engine library. Of course this breaks
toolkits that try to look like gtk using gtk_rc_get_style_by_paths().

(2) Gtkrc talks about widgets but engines draw primitives. E.g. a
GtkNotebook is drawn using "box_gap" and "extender" primitives.
However, there is no vocabulary in gtkrc to configure primitives.

[...] (There are of course dusty corners)

>> - Detail strings are not the problem they're sometimes made to be.
>
> Detail strings are part of the problem. I see two important flaws with
> the current detail strings. The first one is that they are fixed and
> cannot be extended easily because of API compatibility. The second one
> is that there are a lot of inconsistencies in their naming.
> As an example for this look at the different style properties that only
> exists to add more information to detail strings. Or look at the two
> scrollbars and scales. One calls the slider "[hv]scale" the other
> "slider". And guess what? The scrollbar calls the stepper buttons
> "[hv]scrollbar".
>
> Both of these make it harder to create good themes. One needs to shift
> trough a lot of style properties and learn the different quirks of
> widgets -- often by reading the GTK+ source code.

Thinking again, most of the detail strings are actually redundant if
the engine is allowed to know what kind of widget is drawn.

>> Frankly, and this is also heavily influenced by the recent
>> gtk-css-engine work, I think nobody ever tried to push an engine to
>> the edge of what's actually possible.
>
> I do think that you are underestimating the work done by other people
> here. Look at the huge maemo theme. Look at the sugar theme, which while
> looking pretty simple has some interesting issues. Look at the
> Clearlooks engine and all its derivatives. Or maybe the the eXperience
> engine, a very powerful pixmap based engine that never took off ...
>
> There are probably a lot more examples that I do not know about.

I did not mean to say that there are great engines out there or that
they weren't a lot of work, just that the internal gtk/engine
interface is way more powerful that what most engines expose.

[...]

To sum up, here is what I'm prototyping:
- Use CSS vocabulary to match all widgets and primitives.
- Only what is specified in CSS is drawn, nothing is implicit or
special-cased inside the engine.
- Feed back gtkrc snippets created from CSS to support
gtk_rc_get_style_by_paths() [future].

Generally, instead of passing more context information to the engine
as it is being discussed, I'd rather provide hooks to the style
matching subsystem for widget implementers and look mimicking. This is
also the approach taken in the CSS engine.

- Rob
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.18 released

2008-09-02T14:47:11Z

GLib 2.18.0 is now available for download at:

http://download.gnome.org/sources/glib/2.18

glib-2.18.0.tar.bz2 md5sum: 06e5afe4ce055085dc5fd9fdab527bf7
glib-2.18.0.tar.gz md5sum: e55609e7a08755b40d234090f5dfd530

GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality
as an event loop, threads, dynamic loading, and an object system.

GLib 2.18 is a stable release adding an incremental improvement
in functionality over GLib 2.16 while maintaining binary and
source compatibility.

Major new features include:

* Unicode 5.1 support

* Support for the latest version of the shared-mime specification,
including icons for mime types and content types for volumes

* Improved internationalization support with g_dgettext(), g_dngettext()
and NC_()

* Support for "subparsers" in GMarkup

* Support for emblems on icons

* GIO supports HTTP URIs on Windows

For more details and lists of fixed bugs, see the
announcements of the 2.17.x development releases:

http://mail.gnome.org/archives/gtk-devel-list/2008-May/msg00108.html
http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00155.html
http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00156.html
http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00019.html
http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00180.html
http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00010.html
http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00152.html

More information about GLib is available at:

http://www.gtk.org/

The GLib Team:

Hans Breuer, Matthias Clasen, Tim Janik, Tor Lillqvist,
Manish Singh, Owen Taylor, and Sebastian Wilhelmi

Thanks to all the GLib 2.16 contributors, including
Akira Tagoh
Alessandro Morandi
Alessandro Vesely
Alexander Larsson
Andrew Walton
Areg Beketovski
Arfrever Frehtes Taifersar Arahesis
Bastien Nocera
Behdad Esfahbod
Benjamin Otte
Björn Lindqvist
Carlos Garcia Campos
Christian Kellner
Christian Neumair
Christian Persch
Claudio Saavedra
Clemens Buss
Cody Russell
Colin Walters
Cosmio Cecchi
Danny Baumann
David Zeuthen
Emmanuele Bassi
Erik van Pienbroek
Erik Walthinsen
Federico Mena Quintero
Felix Riemann
Hiroyuki Ikezoe
Holger Berndt
Jared Moore
Jean-Yves Lefort
Jeffrey Stedfast
Jens Granseuer
Joe Marcus Clarke
Joe Shaw
Johan Dahlin
John Ehresman
Josselin Mouette
Kalle Vahlman
Kazuki Iwamoto
Kjartan Maraas
Kouhei Sutou
Kristian Rietveld
Lieven van der Heide
Lin Ma
Loïc Minier
Luca Ferretti
Marc-Andre Lureau
Marek Kasik
Markus Bergman
Markus Brinkmann
Mart Raudsepp
Mathias Hasselmann
Michael Meeks
Michael Natterer
Mikkel Kamstrup Erlandsen
Morten Welinder
Mukund Sivaraman
Neil Roberts
Olivier Crete
Padraig O'Briain
Paolo Borelli
Patrik Olsson
Paul Bolle
Paul Pogonyshev
Peter Kjellerstedt
Peter O'Gorman
Priit Laes
Richard Hult
Rob Bradford
Rodrigo Moya
Ross Burton
Ryan Lortie
Ryan Schmidt
Salvatore Iovene
Samuel Thibault
Sebastian Dröge
Sebastien Bacher
Simon Zheng
Sjoerd Simons
Stefan Kost
Sven Herzberg
Sven Neumann
Takao Fujiwara
Ted Percival
Thiago Macieira
Thomas Andersen
Tim-Philipp Müller
Tomas Bzatek
Vlad Grecescu
Yevgen Muntyan
Yukihiro Nakadaira
Yu Kuan

September 2, 2008
Matthias Clasen
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Proposal: Engine Schema inclusion in GTK+

2008-09-02T13:59:17Z

Dear GTK+ Devs!
(If you don't like long introductions, just skip the first chapter)

Chapter 1:

Some time ago I created a very simple XML format[1] that GTK+ engines
could use to expose its (GTKRC) options as well as some metadata like
version number and author contacts. Engines with relatively simple
options like Clearlooks, High Contrast, Industrial, etc are shipped with
such "Engine Schema" files since then, which are used by tools like
GNOME Color Chooser[2] and GTKConf[3] to allow GTK+/GNOME users to
change engine options of a theme.

As the old format (0.1) isn't enough to describe more complex options
like the one of the Pixmap or Smooth GTK+ engine and because engine
authors and GTKConf maintainers would like to have more contextual
information about engine options so that similar options can e.g. be
grouped together in a GUI instead of forcing them to provide just a list
of available options to a user, i decided to update the XML format
specifications.

With version 0.2 of the Engine Schema format, it's now flexible enough
to fully describe Pixmap options[4] and let engines like murrine
structure its huge amount of available parameters. Additionally there's
an XML Schema[5] that documents the format and can be used to validate a
given schema file. GUIs can use it to easily validate schema files found
on a user's computer before loading them to keep the need of own error
checking to a minimum while engine authors can use a validator (e.g.
contained in GNOME Color Chooser trunk) to debug their schemas before
shipping them.

As before, the format has 100% i18n support and can easily be translated
using intltool.

So why do I tell you all this at all?

Chapter 2:

I wondered where to publish the XML Schema[5] that describes the new
Engine Schema format and Benjamin Berg pointed out that it could be nice
to have it shipped with GTK+. This allows easy validation of every
installed engine schema (by tools and engine authors) and prevents those
tools and GTK+ engines from shipping with its own (and maybe even
modified) copy.

You could also ship the Pixmap engine schema[4] with GTK+ if you want.
However, this would require (or even introduce?) the compile-time
dependency of intltool/gettext to GTK+, as it is meant to be translated
into different languages. Also some more explanations to each option
should be added. ;-)

What do you think about such an inclusion, would it be possible/sensible?

I'm also open for discussions on the new engine schema format itself, of
course. Or if anyone of you is into XSD files, feel free to check the
file at [5] as i never created XML Schemas before. ;-)

Best regards,
Werner Pantke

1: http://live.gnome.org/GnomeArt/EngineSchema
2: http://gnomecc.sourceforge.net/
3: https://code.launchpad.net/~gtkconf/murrine/murrine-configurator
4:
http://gnomecc.svn.sourceforge.net/viewvc/gnomecc/gtk-engine-schema/pixmap.xml?content-type=text%2Fplain
5:
http://gnomecc.svn.sourceforge.net/viewvc/gnomecc/gtk-engine-schema/schema_0_2.xsd?content-type=text%2Fplain

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (268 bytes) Download Attachment

Re: [RFC] supporting an alternative layout management algorithm

2008-09-02T10:45:30Z

Matthias Clasen wrote:

> On Tue, Sep 2, 2008 at 1:24 PM, Behdad Esfahbod
>> These changes of your to GTK+ are quite similar to the "ExtendedLayout" work
>> that Mathias Hasselmann has done previously, though that's not merged into
>> GTK+ yet. He also introduces an interface that adds height-for-width and
>> width-for-height methods for sophisticated size allocation. That's a more
>> generic approach than yours from what I understand. See:
>>
>> http://live.gnome.org/MathiasHasselmann/NewLayoutManager
>>
>> Can you give it a test and verify that it is flexible enough for your usecase?
>
> Yes, please.
>
> We'll take a serious effort at integrating the width-for-height work
> in the next cycle, so making sure that it is flexible enough for your
> needs would be very valuable.

Yes, it seems feasible. I think I can implement the flow container by
making a GtkBox subclass that asks for its size like this:

__________
| B1 |
|__________|
| B2 |
|______|_
| B3 |
|________|_
| B4 |
|__________|

... but can trade "height for width" to pack more items on the same
line. This probably is not covered by Matthias' work, and it should be
a worthwhile addition to the first GTK+ release that has extended layout.

And I think the GtkManagedLayout would be replaced simply by GtkViewport
-- but I don't see it on the list on the wiki page, and it might be that
GtkViewport needs to be made aware of extended layouts.

I'll check out the branch but anyway I'll ask, can the code be
"injected" into a current GTK+ release like I'm doing now or does it
touch the very innards of GTK+?

Thanks for the very quick turnaround,

Paolo
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [RFC] supporting an alternative layout management algorithm

2008-09-02T10:30:49Z

On Tue, Sep 2, 2008 at 1:24 PM, Behdad Esfahbod

>
> These changes of your to GTK+ are quite similar to the "ExtendedLayout" work
> that Mathias Hasselmann has done previously, though that's not merged into
> GTK+ yet. He also introduces an interface that adds height-for-width and
> width-for-height methods for sophisticated size allocation. That's a more
> generic approach than yours from what I understand. See:
>
> http://live.gnome.org/MathiasHasselmann/NewLayoutManager
>
> Can you give it a test and verify that it is flexible enough for your usecase?

Yes, please.

We'll take a serious effort at integrating the width-for-height work
in the next cycle, so making sure that it is flexible enough for your
needs would be very valuable.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list