Re: *_type_register_static() and g_intern_static_string()

2007-04-27 Thread Matthias Clasen
On 4/27/07, Damon Chaplin <[EMAIL PROTECTED]> wrote:
>
> Why do the *_type_register_static() functions use
> g_intern_static_string() for the type name?
>
> Should apps be using g_intern_static_string() as well? If so, the docs
> should mention it.

It is just a small optimization. Apps are free to use it, but it is not
the end of the world if they don't.

> There is some inconsistency as well. Some calls don't seem to use it:
> "GtkPaperSize" "GtkTextIter" "GtkRecentInfo" "GtkIconSource"
> "GtkWidget" "GtkIconViewAccessible" "GtkIconViewAccessibleFactory"
> "GtkAssistantAccessible" "GtkAssistantAccessibleFactory"

I'll fix that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: error compiling gtk-2.10.11

2007-04-27 Thread Yevgen Muntyan
Robert Schwebel wrote:
> On Fri, Apr 27, 2007 at 10:56:22AM -0500, Yevgen Muntyan wrote:
>   
>>> --8<--
>>> [snip]
>>> make[3]: *** [gtkbuiltincache.h] Error 1
>>> --8<--
>>>  
>>>   
>> Using debian with gtk-2.8 as host system?
>> 
>
> Yup. Bad enough, but gtk is not very cross compilation friendly in this
> regard. 
It got a *lot* frendlier in this regard ;)
> I'd have to build gtk-update-icon-cache for the host, but in
> order to even configure it in a separate directory, it is necessary to
> install glib/atk/pango/cairo/fontconfig/half-of-X, although it would
> probably only need glib. I've no real idea for a good solution, probably
> something like a '--enable-tools' and '--enable-libs' switches, which
> default to the current case, but make it possible to build only these
> tools necessary for a cross build.
>   
jhbuild is an easy solution; taking gtk-update-icon-cache sources from 
cvs and
building it without gtk is even easier.
>> You need gtk-update-icon-cache from gtk-2.10.
>> 
>
> The code that hardcodes argv[1] to be the filename is equal in both
> versions, so I don't see why it shoud work differently. But maybe I'm
> missing something. Did you test it, or is it just an assumption?
>   
I actually thought gtk-2.10 has new option (--force), never checked it 
really, but
I would be surprised if it wasn't true. Note that argv[1] is taken after 
argv is passed
through GOption stuff, i.e. argv[1] is first non-option argument *after* 
checking
command line options. It's tested - I am using debian, and I use 
separately built
gtk-2.10 for linux (not a huge problem since I do want to test new gtk) 
to build
gtk-2.10 for windows.

Best regards,
Yevgen

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


Re: error compiling gtk-2.10.11

2007-04-27 Thread Robert Schwebel
On Fri, Apr 27, 2007 at 10:56:22AM -0500, Yevgen Muntyan wrote:
> >--8<--
> >/bin/sh ../libtool --mode=link arm-iwmmx-linux-gnueabi-gcc  -g -O2 -Wall  
> >-L/some/path/local/arm-iwmmx-linux-gnueabi/lib 
> >-L/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -Wl,-rpath-link 
> >-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -o 
> >gtk-update-icon-cache  updateiconcache.o 
> >../gdk-pixbuf/libgdk_pixbuf-2.0.la mkdir .libs
> >arm-iwmmx-linux-gnueabi-gcc -g -O2 -Wall -Wl,-rpath-link 
> >-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -o 
> >.libs/gtk-update-icon-cache updateiconcache.o  
> >-L/some/path/local/arm-iwmmx-linux-gnueabi/lib 
> >-L/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib 
> >../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lm
> >creating gtk-update-icon-cache
> >make[4]: Leaving directory `/some/path/build-target/gtk+-2.10.11/gtk'
> >/usr/bin/gtk-update-icon-cache --force --ignore-theme-index \
> >   --source builtin_icons stock-icons > gtkbuiltincache.h.tmp &&   
> >   \
> >mv gtkbuiltincache.h.tmp gtkbuiltincache.h
> >No theme index file in '--force'.
> >If you really want to create an icon cache here, use --ignore-theme-index.
> >make[3]: *** [gtkbuiltincache.h] Error 1
> >--8<--
> >  
> Using debian with gtk-2.8 as host system?

Yup. Bad enough, but gtk is not very cross compilation friendly in this
regard. I'd have to build gtk-update-icon-cache for the host, but in
order to even configure it in a separate directory, it is necessary to
install glib/atk/pango/cairo/fontconfig/half-of-X, although it would
probably only need glib. I've no real idea for a good solution, probably
something like a '--enable-tools' and '--enable-libs' switches, which
default to the current case, but make it possible to build only these
tools necessary for a cross build.

> You need gtk-update-icon-cache from gtk-2.10.

The code that hardcodes argv[1] to be the filename is equal in both
versions, so I don't see why it shoud work differently. But maybe I'm
missing something. Did you test it, or is it just an assumption?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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


Re: Wimp tab rendering patch

2007-04-27 Thread Cody Russell
Lieven, thanks very much for your work on that patch.  It is greatly
appreciated!

On Fri, 2007-04-27 at 10:58 +0200, Lieven van der Heide wrote:
> thx:)
> 
> On 4/27/07, Cody Russell <[EMAIL PROTECTED]> wrote:
> > Yeah, I committed to svn a couple days ago. 


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


error compiling gtk-2.10.11

2007-04-27 Thread Robert Schwebel
Hi,

gtk-update-icon-cache seems to be broken:

--8<--
/bin/sh ../libtool --mode=link arm-iwmmx-linux-gnueabi-gcc  -g -O2 -Wall  
-L/some/path/local/arm-iwmmx-linux-gnueabi/lib 
-L/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -Wl,-rpath-link 
-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -o gtk-update-icon-cache  
updateiconcache.o ../gdk-pixbuf/libgdk_pixbuf-2.0.la 
mkdir .libs
arm-iwmmx-linux-gnueabi-gcc -g -O2 -Wall -Wl,-rpath-link 
-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -o 
.libs/gtk-update-icon-cache updateiconcache.o  
-L/some/path/local/arm-iwmmx-linux-gnueabi/lib 
-L/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib 
../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lm
creating gtk-update-icon-cache
make[4]: Leaving directory `/some/path/build-target/gtk+-2.10.11/gtk'
/usr/bin/gtk-update-icon-cache --force --ignore-theme-index \
   --source builtin_icons stock-icons > gtkbuiltincache.h.tmp &&
\
mv gtkbuiltincache.h.tmp gtkbuiltincache.h
No theme index file in '--force'.
If you really want to create an icon cache here, use --ignore-theme-index.
make[3]: *** [gtkbuiltincache.h] Error 1
--8<--

This is while cross compiling to ARM, so gtk-update-icon-cache is taken from
the distro, which is debian (2.8.20-7), but it seems that also
gtk/updateiconcache.c in 2.10.11 has argv[1] hardcoded to be the icon cache
filename. I'm wondering how this could ever have worked.

To find out what could be done, I temporarily pimped Makefile this way:

--8<--
gtkbuiltincache.h:  stamp-icons
$(MAKE) $(AM_MAKEFLAGS) gtk-update-icon-cache$(EXEEXT)
-   $(gtk_update_icon_cache_program) --force --ignore-theme-index \
+   $(gtk_update_icon_cache_program) . --force --ignore-theme-index 
\
   --source builtin_icons stock-icons > gtkbuiltincache.h.tmp &&
\
mv gtkbuiltincache.h.tmp gtkbuiltincache.h
--8<--

This lets the compiler go ahead, but it breaks here:

--8<--
 arm-iwmmx-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I. -I.. 
-DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/usr/lib\" -DGTK_DATADIR=\"/usr/share\" 
-DGTK_DATA_PREFIX=\"/usr\" -DGTK_SYSCONFDIR=\"/etc\" -DGTK_VERSION=\"2.10.11\" 
-DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"arm-iwmmx-linux-gnueabi\" 
-DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"file,lpr\" 
"-DGTK_PRINT_PREVIEW_COMMAND=\"evince --preview %f\"" -I../gtk -I.. -I../gdk 
-I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED 
-DGDK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED 
-DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_DISABLE_CAST_CHECKS -pthread 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/glib-2.0 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib/glib-2.0/include 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/pango-1.0 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/cairo 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/
 freetype2 -I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/freetype2 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/libpng12 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include/atk-1.0 -isystem 
/some/path/local/arm-iwmmx-linux-gnueabi/include -isystem 
/some/path/local/arm-iwmmx-linux-gnueabi/usr/include 
-I/some/path/local/arm-iwmmx-linux-gnueabi/usr/include -g -O2 -Wall -MT 
gtkicontheme.lo -MD -MP -MF .deps/gtkicontheme.Tpo -c gtkicontheme.c  -fPIC 
-DPIC -o .libs/gtkicontheme.o
gtkicontheme.c: In function '_gtk_icon_theme_ensure_builtin_cache':
gtkicontheme.c:1166: error: 'builtin_icons' undeclared (first use in this 
function)
gtkicontheme.c:1166: error: (Each undeclared identifier is reported only once
gtkicontheme.c:1166: error: for each function it appears in.)
gtkicontheme.c: In function 'load_svg_at_size':
gtkicontheme.c:2553: warning: pointer targets in passing argument 2 of 
'gdk_pixbuf_loader_write' differ in signedness
make[5]: *** [gtkicontheme.lo] Error 1
--8<--

Any idea, anyone?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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


Re: freetype bug (was: Re: Pango-1.16.4 released)

2007-04-27 Thread Robert Schwebel
On Fri, Apr 27, 2007 at 12:18:53PM +0200, Robert Schwebel wrote:
> harfbuzz-dump-main.o: In function `main':
> /some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:225:
> undefined reference to `FT_Init_FreeType'
> /some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:228:
> undefined reference to `FT_New_Face'
> /some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:264:
> undefined reference to `FT_Done_Face'
> /some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:267:
> undefined reference to `FT_Done_FreeType'
> 
> Looks like freetype isn't linked in.

This makes it go away:
 
diff -urN pango-1.16.3-orig/pango/opentype/Makefile.am 
pango-1.16.3/pango/opentype/Makefile.am
--- pango-1.16.3-orig/pango/opentype/Makefile.am2007-01-03 
09:14:56.0 +0100
+++ pango-1.16.3/pango/opentype/Makefile.am 2007-04-27 12:20:44.0 
+0200
@@ -47,7 +47,8 @@
harfbuzz-dump-main.c
 
 harfbuzz_dump_LDADD =  \
-   libharfbuzz-1.la
+   libharfbuzz-1.la \
+   $(FREETYPE_LIBS)
 
 EXTRA_DIST =   \
README  \

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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


freetype bug (was: Re: Pango-1.16.4 released)

2007-04-27 Thread Robert Schwebel
Behdad,

On Fri, Apr 27, 2007 at 03:05:12AM -0400, Behdad Esfahbod wrote:
> Overview of changes between 1.16.3 and 1.16.4
> ==
> - Add new configure option --disable-doc-cross-references and make
>   sure releases are made using it.  Distributions are encouraged to
>   build with --enable-gtk-doc such that their Pango docs correctly
>   cross reference glib and cairo docs.
> - Bugs fixed in this release:
> Bug 432991 ??? developer docs for libpango are broken

When trying to compile pango for ARM, I'm experiencing the following
bug. Tested with 1.16.3 and pango-trunk from five minutes ago:

(cd .libs && rm -f libharfbuzz-1.la && ln -s ../libharfbuzz-1.la 
libharfbuzz-1.la)
/bin/sh ../../libtool --tag=CC --mode=link arm-iwmmx-linux-gnueabi-gcc  -g -O2 
-Wall  -L/some/path/local/arm-iwmmx-linux-gnueabi/lib 
-L/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -Wl,-rpath-link 
-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -o harfbuzz-dump  
harfbuzz-dump-main.o libharfbuzz-1.la 
arm-iwmmx-linux-gnueabi-gcc -g -O2 -Wall -Wl,-rpath-link 
-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -o harfbuzz-dump 
harfbuzz-dump-main.o  -L/some/path/local/arm-iwmmx-linux-gnueabi/lib 
-L/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib ./.libs/libharfbuzz-1.a 
/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib/libz.so -Wl,--rpath 
-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib -Wl,--rpath 
-Wl,/some/path/local/arm-iwmmx-linux-gnueabi/usr/lib
harfbuzz-dump-main.o: In function `main':
/some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:225: 
undefined reference to `FT_Init_FreeType'
/some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:228: 
undefined reference to `FT_New_Face'
/some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:264: 
undefined reference to `FT_Done_Face'
/some/path/build-target/pango-trunk/pango/opentype/harfbuzz-dump-main.c:267: 
undefined reference to `FT_Done_FreeType'

Looks like freetype isn't linked in.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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


*_type_register_static() and g_intern_static_string()

2007-04-27 Thread Damon Chaplin

Why do the *_type_register_static() functions use
g_intern_static_string() for the type name?

Should apps be using g_intern_static_string() as well? If so, the docs
should mention it.

There is some inconsistency as well. Some calls don't seem to use it:
"GtkPaperSize" "GtkTextIter" "GtkRecentInfo" "GtkIconSource"
"GtkWidget" "GtkIconViewAccessible" "GtkIconViewAccessibleFactory"
"GtkAssistantAccessible" "GtkAssistantAccessibleFactory"

Damon


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


Re: Wimp tab rendering patch

2007-04-27 Thread Lieven van der Heide
thx:)

On 4/27/07, Cody Russell <[EMAIL PROTECTED]> wrote:
> Yeah, I committed to svn a couple days ago.
>
> On Thu, 2007-04-26 at 23:00 +0200, Lieven van der Heide wrote:
> > Did you get a chance to look at it?
> >
> > On 4/23/07, Cody Russell <[EMAIL PROTECTED]> wrote:
> > > Sorry I didn't respond.. I got it.  Thanks, I'll get to this later
> > > today, I promise.
> > >
> > > Thanks!
> > >
> > > On Sat, 2007-04-21 at 20:51 +0200, Lieven van der Heide wrote:
> > > > Here you go
> > > >
> > > >
> > > > On 4/20/07, Cody Russell <[EMAIL PROTECTED]> wrote:
> > > > > Hi Lieven,
> > > > >
> > > > > I'm having troubles with the patch for some reason.  Could you maybe
> > > > > just send me a copy of your whole msw_style.c file?
> > > > >
> > > > > / Cody
> > > > >
> > > > > On Sun, 2007-04-01 at 21:46 +0200, Lieven van der Heide wrote:
> > > > > > I made a new version which should work with tabs at any side, and
> > > > > > also,
> > > > > > the stretched packing seems to work fine now.
> > > > > >
> > > > > > My patch is still against revision 17429. Maybe someone can test it,
> > > > > > and if it
> > > > > > works I can merge it with cody's changes (It will probably conflict 
> > > > > > if
> > > > > > I do an
> > > > > > update right now).
> > > > > >
> > > > > > On my computer, GPS looks fine aswell. If you still have those
> > > > > > problems, could you make
> > > > > > a screenshot of it? I will have a look at the notebook source to see
> > > > > > how the
> > > > > > rectangle is calculated, and try to match it in the theming code.
> > > > >
> > > > >
> > >
> > >
> --
> Cody Russell
> http://www.gnome.org/~bratsche/
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk.org about page

2007-04-27 Thread Martyn Russell
Felix Rabe (public) wrote:
> Hi,
> 
> http://www.google.com/search?q=link%3Ahttp%3A%2F%2Fwww.gtk.org%2Fabout.html
> 
> There is going to be a link to the page on the main page, right?

Yes.

-- 
Regards,
Martyn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Pango-1.16.4 released

2007-04-27 Thread Behdad Esfahbod
Pango-1.16.4 is now available for download at:

  http://download.gnome.org/sources/pango/1.16/

025e2ac5e40cac163aae4653aeef559c  pango-1.16.4.tar.bz2
1d9e2081774f3e39c926175de96bdd50  pango-1.16.4.tar.gz

This is a stable release and is source and binary compatible
with previous 1.16.x releases.


About Pango
===

Pango is a library for layout and rendering of text, with an emphasis
on internationalization. Pango can be used anywhere that text layout
is needed, though most of the work on Pango so far has been done in
the context of the GTK+ widget toolkit. Pango forms the core of text
and font handling for GTK+-2.x.

Pango is designed to be modular; the core Pango layout engine can
be used with different font backends. There are three basic backends,
with multiple options for rendering with each.

 - Client side fonts using the FreeType and fontconfig libraries.
   Rendering can be with with Cairo or Xft libraries, or directly
   to an in-memory buffer with no additional libraries.

 - Native fonts on Microsoft Windows using Uniscribe for complex-text
   handling. Rendering can be done via Cairo or directly using the
   native Win32 API.

 - Native fonts on MacOS X, rendering via Cairo.

The integration of Pango with Cairo (http://cairographics.org)
provides a complete solution with high quality text handling
and graphics rendering.

Dynamically loaded modules then handle text layout for particular
combinations of script and font backend. Pango ships with a wide
selection of modules, including modules for Hebrew, Arabic,
Hangul, Thai, and a number of Indic scripts. Virtually all of the
world's major scripts are supported.

As well as the low level layout rendering routines, Pango includes
PangoLayout, a high level driver for laying out entire blocks of text,
and routines to assist in editing internationalized text.

More information about Pango is available from http://www.pango.org/.
Bugs should be reported to http://bugzilla.gnome.org.

Pango 1.16 depends on version 2.12.0 or newer of the GLib
library and version 1.2.6 or newer of the cairo library (if the
cairo backend is desired); more information about GLib and cairo
can be found at http://www.gtk.org/ and http://cairographics.org/
respectively.

Overview of changes between 1.16.3 and 1.16.4
==
- Add new configure option --disable-doc-cross-references and make
  sure releases are made using it.  Distributions are encouraged to
  build with --enable-gtk-doc such that their Pango docs correctly
  cross reference glib and cairo docs.
- Bugs fixed in this release:
Bug 432991 – developer docs for libpango are broken

Overview of changes between 1.16.2 and 1.16.3
==
- Quantize kerning value if metrics hinting is on.  This greatly improves
  screen text rendering with certain fonts like DejaVu Sans.
  See: http://behdad.org/blog/mces/image/metricshinting-kerning.png
- Improved hex-box positioning in the cairo backend


Behdad Esfahbod
27 April 2007



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list