SVG support(again) ?

SVG support(again) ?

[joakim]

There was a patch for SVG support in Emacs in 2004.
This patch seems to no longer apply.

Has anyone adopted it for the current tree? If so, coculd it be
applied?

-- 
Joakim Verona

Re: SVG support(again) ?

[joakim]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

joakim@verona.se writes:

> There was a patch for SVG support in Emacs in 2004.
> This patch seems to no longer apply.

I've adapted the SVG patch by Paul Pogonyshev for current emacs CVS.
All I did was find the right place to insert the hunks, since the
emacs source has changed a lot since the original patch.

I tried it briefly on a Fedora 7 box. It seems to work nicely.

What must be done in order for this patch to be applied?

The only odd thing I can see is three lines like:

#if 1 || defined (HAVE_RSVG)

that ought to be the same as:

#if defined (HAVE_RSVG)

which should be ok on any plattform, since HAVE_RSVG will be defined
only if you have librsvg2. I did try the configure script generated by
autoconf once withouth the lib and once with.

I tried making a SVG picture with Inkscape, viewing it in emacs using
image-dired, and then editing it a bit with nxml mode, and it seemed
to work nicely.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs_svg.patch --]
[-- Type: text/x-patch, Size: 10760 bytes --]

? emacs_svg.patch
Index: configure.in
===================================================================
RCS file: /sources/emacs/emacs/configure.in,v
retrieving revision 1.459
diff -r1.459 configure.in
112a113,114
> AC_ARG_WITH(rsvg,
> [  --with-rsvg             use -lrsvg-2 for displaying SVG images])
116c118
< [  --with-pkg-config-prog  Path to pkg-config to use for finding GTK])
---
> [  --with-pkg-config-prog  Path to pkg-config to use for finding GTK and librsvg])
2124a2127,2152
> ### Use -lrsvg-2 if available, unless `--with-rsvg=no' is specified.
> HAVE_RSVG=no
> if test "${HAVE_X11}" = "yes"; then
>   if test "${with_rsvg}" != "no"; then
>     dnl Check if `--with-pkg-config-prog' has been given.
>     if test "X${with_pkg_config_prog}" != X; then
>       PKG_CONFIG="${with_pkg_config_prog}"
>     fi
> 
>     RSVG_REQUIRED=2.0.0
>     RSVG_MODULE="librsvg-2.0 >= $RSVG_REQUIRED"
> 
>     PKG_CHECK_MODULES(RSVG, $RSVG_MODULE, :, :)
>     AC_SUBST(RSVG_CFLAGS)
>     AC_SUBST(RSVG_LIBS)
> 
>     if test ".${RSVG_CFLAGS}" != "."; then
>       HAVE_RSVG=yes
>       AC_DEFINE(HAVE_RSVG, 1, [Define to 1 if using librsvg.])
>       CFLAGS="$CFLAGS $RSVG_CFLAGS"
>       LIBS="$RSVG_LIBS $LIBS"
>     fi
>   fi
> fi
> 
> 
3364a3393
> echo "  Does Emacs use -lrsvg-2?                                ${HAVE_RSVG}"
Index: lisp/image-file.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/image-file.el,v
retrieving revision 1.29
diff -r1.29 image-file.el
42c42
<   '("png" "jpeg" "jpg" "gif" "tiff" "tif" "xbm" "xpm" "pbm" "pgm" "ppm" "pnm")
---
>   '("png" "jpeg" "jpg" "gif" "tiff" "tif" "xbm" "xpm" "pbm" "pgm" "ppm" "pnm" "svg")
Index: lisp/image.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/image.el,v
retrieving revision 1.72
diff -r1.72 image.el
46c46,47
<     ("\\`\xff\xd8" . (image-jpeg-p . jpeg)))
---
>     ("\\`\xff\xd8" . (image-jpeg-p . jpeg))
>     ("\\`<\\?xml " . svg))
Index: src/Makefile.in
===================================================================
RCS file: /sources/emacs/emacs/src/Makefile.in,v
retrieving revision 1.346
diff -r1.346 Makefile.in
284c284
< ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} C_SWITCH_MACHINE C_SWITCH_SYSTEM C_SWITCH_SITE C_SWITCH_X_SITE C_SWITCH_X_MACHINE C_SWITCH_X_SYSTEM C_SWITCH_SYSTEM_TEMACS ${CFLAGS_SOUND} ${CFLAGS}
---
> ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} C_SWITCH_MACHINE C_SWITCH_SYSTEM C_SWITCH_SITE @RSVG_CFLAGS@ C_SWITCH_X_SITE C_SWITCH_X_MACHINE C_SWITCH_X_SYSTEM C_SWITCH_SYSTEM_TEMACS ${CFLAGS_SOUND} ${CFLAGS}
453c453
< LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM $(XFT_LIBS)
---
> LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM @RSVG_LIBS@ LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM $(XFT_LIBS)
Index: src/image.c
===================================================================
RCS file: /sources/emacs/emacs/src/image.c,v
retrieving revision 1.77
diff -r1.77 image.c
8201a8202,8474
>  
> /***********************************************************************
> 				 SVG
>  ***********************************************************************/
> 
> #if 1 || defined (HAVE_RSVG)
> 
> /* Function prototypes.  */
> 
> static int svg_image_p P_ ((Lisp_Object object));
> static int svg_load P_ ((struct frame *f, struct image *img));
> 
> static int svg_load_image P_ ((struct frame *, struct image *,
> 			       unsigned char *, unsigned int));
> 
> /* The symbol `svg' identifying images of this type. */
> 
> Lisp_Object Qsvg;
> 
> /* Indices of image specification fields in svg_format, below.  */
> 
> enum svg_keyword_index
> {
>   SVG_TYPE,
>   SVG_DATA,
>   SVG_FILE,
>   SVG_ASCENT,
>   SVG_MARGIN,
>   SVG_RELIEF,
>   SVG_ALGORITHM,
>   SVG_HEURISTIC_MASK,
>   SVG_MASK,
>   SVG_BACKGROUND,
>   SVG_LAST
> };
> 
> /* Vector of image_keyword structures describing the format
>    of valid user-defined image specifications.  */
> 
> static struct image_keyword svg_format[SVG_LAST] =
> {
>   {":type",		IMAGE_SYMBOL_VALUE,			1},
>   {":data",		IMAGE_STRING_VALUE,			0},
>   {":file",		IMAGE_STRING_VALUE,			0},
>   {":ascent",		IMAGE_ASCENT_VALUE,			0},
>   {":margin",		IMAGE_POSITIVE_INTEGER_VALUE_OR_PAIR,	0},
>   {":relief",		IMAGE_INTEGER_VALUE,			0},
>   {":conversion",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
>   {":heuristic-mask",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
>   {":mask",		IMAGE_DONT_CHECK_VALUE_TYPE,		0},
>   {":background",	IMAGE_STRING_OR_NIL_VALUE,		0}
> };
> 
> /* Structure describing the image type `svg'.  */
> 
> static struct image_type svg_type =
> {
>   &Qsvg,
>   svg_image_p,
>   svg_load,
>   x_clear_image,
>   NULL
> };
> 
> 
> /* Return non-zero if OBJECT is a valid SVG image specification.  */
> 
> static int
> svg_image_p (object)
>      Lisp_Object object;
> {
>   struct image_keyword fmt[SVG_LAST];
>   bcopy (svg_format, fmt, sizeof fmt);
> 
>   if (!parse_image_spec (object, fmt, SVG_LAST, Qsvg))
>     return 0;
> 
>   /* Must specify either the :data or :file keyword.  */
>   return fmt[SVG_FILE].count + fmt[SVG_DATA].count == 1;
> }
> 
> #include <librsvg/rsvg.h>
> 
> /* DEF_IMGLIB_FN() here? */
> 
> #define fn_rsvg_handle_new		rsvg_handle_new
> #define fn_rsvg_handle_set_size_callback rsvg_handle_set_size_callback
> #define fn_rsvg_handle_write		rsvg_handle_write
> #define fn_rsvg_handle_close		rsvg_handle_close
> #define fn_rsvg_handle_get_pixbuf	rsvg_handle_get_pixbuf
> #define fn_rsvg_handle_free		rsvg_handle_free
> 
> #define fn_gdk_pixbuf_get_width		gdk_pixbuf_get_width
> #define fn_gdk_pixbuf_get_height	gdk_pixbuf_get_height
> #define fn_gdk_pixbuf_get_pixels	gdk_pixbuf_get_pixels
> #define fn_gdk_pixbuf_get_rowstride	gdk_pixbuf_get_rowstride
> #define fn_gdk_pixbuf_get_colorspace	gdk_pixbuf_get_colorspace
> #define fn_gdk_pixbuf_get_n_channels	gdk_pixbuf_get_n_channels
> #define fn_gdk_pixbuf_get_has_alpha	gdk_pixbuf_get_has_alpha
> #define fn_gdk_pixbuf_get_bits_per_sample gdk_pixbuf_get_bits_per_sample
> 
> 
> /* Load SVG image IMG for use on frame F.  Value is non-zero if
>    successful.  */
> 
> static int
> svg_load (f, img)
>      struct frame *f;
>      struct image *img;
> {
>   int success_p = 0;
>   Lisp_Object file_name;
> 
>   /* If IMG->spec specifies a file name, create a non-file spec from it.  */
>   file_name = image_spec_value (img->spec, QCfile, NULL);
>   if (STRINGP (file_name))
>     {
>       Lisp_Object file;
>       unsigned char *contents;
>       int size;
>       struct gcpro gcpro1;
> 
>       file = x_find_image_file (file_name);
>       GCPRO1 (file);
>       if (!STRINGP (file))
>       {
>         image_error ("Cannot find image file `%s'", file_name, Qnil);
>         UNGCPRO;
>         return 0;
>       }
> 
>       contents = slurp_file (SDATA (file), &size);
>       if (contents == NULL)
>       {
>         image_error ("Error loading SVG image `%s'", img->spec, Qnil);
>         UNGCPRO;
>         return 0;
>       }
> 
>       success_p = svg_load_image (f, img, contents, size);
>       xfree (contents);
>       UNGCPRO;
>     }
>   else
>     {
>       Lisp_Object data;
> 
>       data = image_spec_value (img->spec, QCdata, NULL);
>       success_p = svg_load_image (f, img, SDATA (data), SBYTES (data));
>     }
> 
>   return success_p;
> }
> 
> 
> static int
> svg_load_image (f, img, contents, size)
>      struct frame *f;
>      struct image *img;
>      unsigned char *contents;
>      unsigned int size;
> {
>   RsvgHandle *rsvg_handle;
>   GError *error = NULL;
>   GdkPixbuf *pixbuf;
>   int width;
>   int height;
>   const guint8 *pixels;
>   int rowstride;
>   XImagePtr ximg;
>   XColor background;
>   int x;
>   int y;
> 
>   g_type_init ();
>   rsvg_handle = fn_rsvg_handle_new ();
> 
>   fn_rsvg_handle_write (rsvg_handle, contents, size, &error);
>   if (error)
>     goto rsvg_error;
> 
>   fn_rsvg_handle_close (rsvg_handle, &error);
>   if (error)
>     goto rsvg_error;
> 
>   pixbuf = fn_rsvg_handle_get_pixbuf (rsvg_handle);
>   eassert (pixbuf);
> 
>   width     = fn_gdk_pixbuf_get_width (pixbuf);
>   height    = fn_gdk_pixbuf_get_height (pixbuf);
>   pixels    = fn_gdk_pixbuf_get_pixels (pixbuf);
>   rowstride = fn_gdk_pixbuf_get_rowstride (pixbuf);
> 
>   eassert (fn_gdk_pixbuf_get_colorspace (pixbuf) == GDK_COLORSPACE_RGB);
>   eassert (fn_gdk_pixbuf_get_n_channels (pixbuf) == 4);
>   eassert (fn_gdk_pixbuf_get_has_alpha (pixbuf));
>   eassert (fn_gdk_pixbuf_get_bits_per_sample (pixbuf) == 8);
> 
>   if (!x_create_x_image_and_pixmap (f, width, height, 0, &ximg, &img->pixmap)) {
>     g_object_unref (pixbuf);
>     return 0;
>   }
> 
>   init_color_table ();
> 
> #ifdef HAVE_X_WINDOWS
> 
>   background.pixel = FRAME_BACKGROUND_PIXEL (f);
>   x_query_color (f, &background);
> 
>   background.red   >>= 8;
>   background.green >>= 8;
>   background.blue  >>= 8;
> 
> #else /* not HAVE_X_WINDOWS */
> #error FIXME
> #endif
> 
>   for (y = 0; y < height; ++y)
>     {
>       for (x = 0; x < width; ++x)
> 	{
> 	  unsigned red;
> 	  unsigned green;
> 	  unsigned blue;
> 	  unsigned opacity;
> 
> 	  red     = *pixels++;
> 	  green   = *pixels++;
> 	  blue    = *pixels++;
> 	  opacity = *pixels++;
> 
> 	  red   = ((red * opacity)
> 		   + (background.red * ((1 << 8) - opacity)));
> 	  green = ((green * opacity)
> 		   + (background.green * ((1 << 8) - opacity)));
> 	  blue  = ((blue * opacity)
> 		   + (background.blue * ((1 << 8) - opacity)));
> 
> 	  XPutPixel (ximg, x, y, lookup_rgb_color (f, red, green, blue));
> 	}
> 
>       pixels += rowstride - 4 * width;
>     }
> 
> #ifdef COLOR_TABLE_SUPPORT
>   /* Remember colors allocated for this image.  */
>   img->colors = colors_in_color_table (&img->ncolors);
>   free_color_table ();
> #endif /* COLOR_TABLE_SUPPORT */
> 
>   g_object_unref (pixbuf);
> 
>   /* Put the image into the pixmap, then free the X image and its buffer. */
>   x_put_x_image (f, ximg, img->pixmap, width, height);
>   x_destroy_x_image (ximg);
> 
>   img->width  = width;
>   img->height = height;
> 
>   return 1;
> 
>  rsvg_error:
>   /* FIXME: Use error->message. */
>   image_error ("Error parsing SVG image `%s'", img->spec, Qnil);
>   g_error_free (error);
>   return 0;
> }
> 
> #endif	/* defined (HAVE_RSVG) */
> 
> 
> 
8593a8867,8871
> #if 1 || defined (HAVE_RSVG)
>   if (EQ (type, Qsvg))
>     return CHECK_LIB_AVAILABLE (&svg_type, init_svg_functions, libraries);
> #endif
>   
8735a9014,9020
> #if 1 || defined (HAVE_RSVG)
>   Qsvg = intern ("svg");
>   staticpro (&Qsvg);
>   ADD_IMAGE_TYPE(Qsvg);
> #endif
> 
>   

[-- Attachment #3: Type: text/plain, Size: 124 bytes --]



>
> Has anyone adopted it for the current tree? If so, coculd it be
> applied?
>
> -- 
> Joakim Verona

-- 
Joakim Verona

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: SVG support(again) ?

[David Kastrup]

joakim@verona.se writes:

> joakim@verona.se writes:
>
>> There was a patch for SVG support in Emacs in 2004.
>> This patch seems to no longer apply.
>
> I've adapted the SVG patch by Paul Pogonyshev for current emacs CVS.
> All I did was find the right place to insert the hunks, since the
> emacs source has changed a lot since the original patch.
>
> I tried it briefly on a Fedora 7 box. It seems to work nicely.
>
> What must be done in order for this patch to be applied?
>
> The only odd thing I can see is three lines like:
>
> #if 1 || defined (HAVE_RSVG)
>
> that ought to be the same as:
>
> #if defined (HAVE_RSVG)

No, it is the same as
#if 1
period.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: SVG support(again) ?

[Jason Rumney]

David Kastrup wrote:
>> The only odd thing I can see is three lines like:
>>
>> #if 1 || defined (HAVE_RSVG)
>>
>> that ought to be the same as:
>>
>> #if defined (HAVE_RSVG)
>>     
>
> No, it is the same as
> #if 1
> period.
>   

Going back and looking at the original discussion from Sept 2004, the 1
|| is there because he hadn't bothered with the configury stuff that
would have made the HAVE_RSVG work.

Re: SVG support(again) ?

[joakim]

David Kastrup <dak@gnu.org> writes:

> joakim@verona.se writes:
>
>> joakim@verona.se writes:
>>
>>> There was a patch for SVG support in Emacs in 2004.
>>> This patch seems to no longer apply.
>>
>> I've adapted the SVG patch by Paul Pogonyshev for current emacs CVS.
>> All I did was find the right place to insert the hunks, since the
>> emacs source has changed a lot since the original patch.
>>
>> I tried it briefly on a Fedora 7 box. It seems to work nicely.
>>
>> What must be done in order for this patch to be applied?
>>
>> The only odd thing I can see is three lines like:
>>
>> #if 1 || defined (HAVE_RSVG)
>>
>> that ought to be the same as:
>>
>> #if defined (HAVE_RSVG)
>
> No, it is the same as
> #if 1
> period.

Thanks! I suppose I should get more sleep.

#if defined (HAVE_RSVG)

seems to work though. Am I missing something else?

>
> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Joakim Verona

Re: SVG support(again) ?

[joakim]

Jason Rumney <jasonr@gnu.org> writes:

> Going back and looking at the original discussion from Sept 2004, the 1
> || is there because he hadn't bothered with the configury stuff that
> would have made the HAVE_RSVG work.

I think the configury stuff does work, but maybe it didnt originaly.

This line in configure.in:

echo "  Does Emacs use -lrsvg-2?                                ${HAVE_RSVG}"

corectly prints "yes" if librsvg2-devel is installed, but "no" if it
isnt. The rest of the code gets to be correct if "#if 1 ..." is changed
to "if defined(HAVE_RSVG)" in  the patch.



-- 
Joakim Verona

Re: SVG support(again) ?

[Richard Stallman]

    I've adapted the SVG patch by Paul Pogonyshev for current emacs CVS.
    All I did was find the right place to insert the hunks, since the
    emacs source has changed a lot since the original patch.

    I tried it briefly on a Fedora 7 box. It seems to work nicely.

    What must be done in order for this patch to be applied?

We have the legal papers.  The code needs more comments.  We also need
the entry for etc/NEWS, and it would be nice to write text for the
manual now.  (I will polish it up once it is installed.)

Re: SVG support(again) ?

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     I've adapted the SVG patch by Paul Pogonyshev for current emacs CVS.
>     All I did was find the right place to insert the hunks, since the
>     emacs source has changed a lot since the original patch.
>
>     I tried it briefly on a Fedora 7 box. It seems to work nicely.
>
>     What must be done in order for this patch to be applied?
>
> We have the legal papers.  The code needs more comments.  We also need
> the entry for etc/NEWS, and it would be nice to write text for the
> manual now.  (I will polish it up once it is installed.)

- Is this text for NEWS ok?

** Support for SVG images

Emacs now supports the SVG image format through librsvg2.


- There appears to be only generic text in the emacs manual for image
  viewing, valid for all image types. Viewing SVG images is no
  different from viewing JPG images, so I think the manual doesnt need
  any particular updates for this patch.

- I looked through the code briefly, and it didnt seem too bad on the
  commenting. Was it anything in particular you thought needed clarification?
  
-- 
Joakim Verona

Re: SVG support(again) ?

[Richard Stallman]

    - Is this text for NEWS ok?

    ** Support for SVG images

    Emacs now supports the SVG image format through librsvg2.

Yes, it is good enough.

    - I looked through the code briefly, and it didnt seem too bad on the
      commenting. Was it anything in particular you thought needed clarification?

There are functions that don't even have a comment at the beginning to
say what they do and how to call them.  It needs a lot of improvement
in comments.

Re: SVG support(again) ?

[Mathias Dahl]

>     - I looked through the code briefly, and it didnt seem too bad on the
>       commenting. Was it anything in particular you thought needed clarification?
>
> There are functions that don't even have a comment at the beginning to
> say what they do and how to call them.  It needs a lot of improvement
> in comments.

This is why I like M-x checkdoc RET so much :)

Re: SVG support(again) ?

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     - Is this text for NEWS ok?
>
>     ** Support for SVG images
>
>     Emacs now supports the SVG image format through librsvg2.
>
> Yes, it is good enough.
>
>     - I looked through the code briefly, and it didnt seem too bad on the
>       commenting. Was it anything in particular you thought needed clarification?
>
> There are functions that don't even have a comment at the beginning to
> say what they do and how to call them.  It needs a lot of improvement
> in comments.

I did some commenting in the SVG handler part of image.c below.
The code seems to be mostly the same as for other image formats in
image.c.

Is it ok to discuss this part of the patch like this, and then I can
supply a new combined patch for consideration?

(again, I'm not the patchs original author, I'm just trying to help out to
get it clean enough for inclusion.)
 
/***********************************************************************
				 SVG
 ***********************************************************************/

#if defined (HAVE_RSVG)

/* Function prototypes.  */

static int svg_image_p P_ ((Lisp_Object object));
static int svg_load P_ ((struct frame *f, struct image *img));

static int svg_load_image P_ ((struct frame *, struct image *,
			       unsigned char *, unsigned int));

/* The symbol `svg' identifying images of this type. */

Lisp_Object Qsvg;

/* Indices of image specification fields in svg_format, below.  */

enum svg_keyword_index
{
  SVG_TYPE,
  SVG_DATA,
  SVG_FILE,
  SVG_ASCENT,
  SVG_MARGIN,
  SVG_RELIEF,
  SVG_ALGORITHM,
  SVG_HEURISTIC_MASK,
  SVG_MASK,
  SVG_BACKGROUND,
  SVG_LAST
};

/* Vector of image_keyword structures describing the format
   of valid user-defined image specifications.  */

static struct image_keyword svg_format[SVG_LAST] =
{
  {":type",		IMAGE_SYMBOL_VALUE,			1},
  {":data",		IMAGE_STRING_VALUE,			0},
  {":file",		IMAGE_STRING_VALUE,			0},
  {":ascent",		IMAGE_ASCENT_VALUE,			0},
  {":margin",		IMAGE_POSITIVE_INTEGER_VALUE_OR_PAIR,	0},
  {":relief",		IMAGE_INTEGER_VALUE,			0},
  {":conversion",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":heuristic-mask",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":mask",		IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":background",	IMAGE_STRING_OR_NIL_VALUE,		0}
};

/* Structure describing the image type `svg'.  */

static struct image_type svg_type =
{
  &Qsvg,
  svg_image_p,
  svg_load,
  x_clear_image,
  NULL
};


/* Return non-zero if OBJECT is a valid SVG image specification.  */

static int
svg_image_p (object)
     Lisp_Object object;
{
  struct image_keyword fmt[SVG_LAST];
  bcopy (svg_format, fmt, sizeof fmt);

  if (!parse_image_spec (object, fmt, SVG_LAST, Qsvg))
    return 0;

  /* Must specify either the :data or :file keyword.  */
  return fmt[SVG_FILE].count + fmt[SVG_DATA].count == 1;
}

#include <librsvg/rsvg.h>

/* DEF_IMGLIB_FN() here? */

#define fn_rsvg_handle_new		rsvg_handle_new
#define fn_rsvg_handle_set_size_callback rsvg_handle_set_size_callback
#define fn_rsvg_handle_write		rsvg_handle_write
#define fn_rsvg_handle_close		rsvg_handle_close
#define fn_rsvg_handle_get_pixbuf	rsvg_handle_get_pixbuf
#define fn_rsvg_handle_free		rsvg_handle_free

#define fn_gdk_pixbuf_get_width		gdk_pixbuf_get_width
#define fn_gdk_pixbuf_get_height	gdk_pixbuf_get_height
#define fn_gdk_pixbuf_get_pixels	gdk_pixbuf_get_pixels
#define fn_gdk_pixbuf_get_rowstride	gdk_pixbuf_get_rowstride
#define fn_gdk_pixbuf_get_colorspace	gdk_pixbuf_get_colorspace
#define fn_gdk_pixbuf_get_n_channels	gdk_pixbuf_get_n_channels
#define fn_gdk_pixbuf_get_has_alpha	gdk_pixbuf_get_has_alpha
#define fn_gdk_pixbuf_get_bits_per_sample gdk_pixbuf_get_bits_per_sample


/* Load SVG image IMG for use on frame F.  Value is non-zero if
   successful.  */

static int
svg_load (f, img)
     struct frame *f;
     struct image *img;
{
  int success_p = 0;
  Lisp_Object file_name;

  /* If IMG->spec specifies a file name, create a non-file spec from it.  */
  file_name = image_spec_value (img->spec, QCfile, NULL);
  if (STRINGP (file_name))
    {
      Lisp_Object file;
      unsigned char *contents;
      int size;
      struct gcpro gcpro1;

      file = x_find_image_file (file_name);
      GCPRO1 (file);
      if (!STRINGP (file))
      {
        image_error ("Cannot find image file `%s'", file_name, Qnil);
        UNGCPRO;
        return 0;
      }

      contents = slurp_file (SDATA (file), &size);
      if (contents == NULL)
      {
        image_error ("Error loading SVG image `%s'", img->spec, Qnil);
        UNGCPRO;
        return 0;
      }

      success_p = svg_load_image (f, img, contents, size);
      xfree (contents);
      UNGCPRO;
    }
  else
    {
      Lisp_Object data;

      data = image_spec_value (img->spec, QCdata, NULL);
      success_p = svg_load_image (f, img, SDATA (data), SBYTES (data));
    }

  return success_p;
}

/* helper function for svg_load, does the actual loading
 given contents and size, apart from frame and image structures, passed from svg_load

 Uses librsvg to do most of the image processing.
 
 Returns non-zero when sucessful
*/
static int
svg_load_image (f, img, contents, size)
     struct frame *f;
     struct image *img;
     unsigned char *contents;
     unsigned int size;
{
  RsvgHandle *rsvg_handle;
  GError *error = NULL;
  GdkPixbuf *pixbuf;
  int width;
  int height;
  const guint8 *pixels;
  int rowstride;
  XImagePtr ximg;
  XColor background;
  int x;
  int y;

  g_type_init ();
  rsvg_handle = fn_rsvg_handle_new ();

  fn_rsvg_handle_write (rsvg_handle, contents, size, &error);
  if (error)
    goto rsvg_error;

  fn_rsvg_handle_close (rsvg_handle, &error);
  if (error)
    goto rsvg_error;

  pixbuf = fn_rsvg_handle_get_pixbuf (rsvg_handle);
  eassert (pixbuf);

  width     = fn_gdk_pixbuf_get_width (pixbuf);
  height    = fn_gdk_pixbuf_get_height (pixbuf);
  pixels    = fn_gdk_pixbuf_get_pixels (pixbuf);
  rowstride = fn_gdk_pixbuf_get_rowstride (pixbuf);

  eassert (fn_gdk_pixbuf_get_colorspace (pixbuf) == GDK_COLORSPACE_RGB);
  eassert (fn_gdk_pixbuf_get_n_channels (pixbuf) == 4);
  eassert (fn_gdk_pixbuf_get_has_alpha (pixbuf));
  eassert (fn_gdk_pixbuf_get_bits_per_sample (pixbuf) == 8);

  if (!x_create_x_image_and_pixmap (f, width, height, 0, &ximg, &img->pixmap)) {
    g_object_unref (pixbuf);
    return 0;
  }

  init_color_table ();

#ifdef HAVE_X_WINDOWS

  background.pixel = FRAME_BACKGROUND_PIXEL (f);
  x_query_color (f, &background);

  background.red   >>= 8;
  background.green >>= 8;
  background.blue  >>= 8;

#else /* not HAVE_X_WINDOWS */
#error FIXME
#endif

  /* this loop handles opacity values, since emacs assumes non-transparent images.
   */
  for (y = 0; y < height; ++y)
    {
      for (x = 0; x < width; ++x)
	{
	  unsigned red;
	  unsigned green;
	  unsigned blue;
	  unsigned opacity;

	  red     = *pixels++;
	  green   = *pixels++;
	  blue    = *pixels++;
	  opacity = *pixels++;

	  red   = ((red * opacity)
		   + (background.red * ((1 << 8) - opacity)));
	  green = ((green * opacity)
		   + (background.green * ((1 << 8) - opacity)));
	  blue  = ((blue * opacity)
		   + (background.blue * ((1 << 8) - opacity)));

	  XPutPixel (ximg, x, y, lookup_rgb_color (f, red, green, blue));
	}

      pixels += rowstride - 4 * width;
    }

#ifdef COLOR_TABLE_SUPPORT
  /* Remember colors allocated for this image.  */
  img->colors = colors_in_color_table (&img->ncolors);
  free_color_table ();
#endif /* COLOR_TABLE_SUPPORT */

  g_object_unref (pixbuf);

  /* Put the image into the pixmap, then free the X image and its buffer. */
  x_put_x_image (f, ximg, img->pixmap, width, height);
  x_destroy_x_image (ximg);

  img->width  = width;
  img->height = height;

  return 1;

 rsvg_error:
  /* FIXME: Use error->message. */
  image_error ("Error parsing SVG image `%s'", img->spec, Qnil);
  g_error_free (error);
  return 0;
}

#endif	/* defined (HAVE_RSVG) */


-- 
Joakim Verona

Re: SVG support(again) ?

[Richard Stallman]

    /* Structure describing the image type `svg'.  */

    static struct image_type svg_type =
    {
      &Qsvg,
      svg_image_p,
      svg_load,
      x_clear_image,
      NULL
    };

How about adding another comment for each field explaining what
the field means and why this particular value is used.

    /* DEF_IMGLIB_FN() here? */

I don't understand that comment -- if you do, could you make
it less terse, and clear?

    /* helper function for svg_load, does the actual loading
     given contents and size, apart from frame and image structures, passed from svg_load

     Uses librsvg to do most of the image processing.

     Returns non-zero when sucessful
    */

That is terse and cryptic.  Could you rewrite it to be clear
and format it the way we like to do?

The code of svg_load_image needs more comments explaining what the
parts of the code do.

Re: SVG support(again) ?

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     /* Structure describing the image type `svg'.  */
>
>     static struct image_type svg_type =
>     {
>       &Qsvg,
>       svg_image_p,
>       svg_load,
>       x_clear_image,
>       NULL
>     };
>
> How about adding another comment for each field explaining what
> the field means and why this particular value is used.
>
>     /* DEF_IMGLIB_FN() here? */
>
> I don't understand that comment -- if you do, could you make
> it less terse, and clear?
>
>     /* helper function for svg_load, does the actual loading
>      given contents and size, apart from frame and image structures, passed from svg_load
>
>      Uses librsvg to do most of the image processing.
>
>      Returns non-zero when sucessful
>     */
>
> That is terse and cryptic.  Could you rewrite it to be clear
> and format it the way we like to do?
>
> The code of svg_load_image needs more comments explaining what the
> parts of the code do.

Here is a new try. I believe this is quite readable now.
Note that some of the difficulty in understanding this code comes from
reading it in isolation from the other code im image.c. I tried
adding some helpful pointers to other emacs code.


/***********************************************************************
				 SVG
 ***********************************************************************/

#if defined (HAVE_RSVG)

/* Function prototypes.  */

static int svg_image_p P_ ((Lisp_Object object));
static int svg_load P_ ((struct frame *f, struct image *img));

static int svg_load_image P_ ((struct frame *, struct image *,
			       unsigned char *, unsigned int));

/* The symbol `svg' identifying images of this type. */

Lisp_Object Qsvg;

/* Indices of image specification fields in svg_format, below.  */

enum svg_keyword_index
{
  SVG_TYPE,
  SVG_DATA,
  SVG_FILE,
  SVG_ASCENT,
  SVG_MARGIN,
  SVG_RELIEF,
  SVG_ALGORITHM,
  SVG_HEURISTIC_MASK,
  SVG_MASK,
  SVG_BACKGROUND,
  SVG_LAST
};

/* Vector of image_keyword structures describing the format
   of valid user-defined image specifications.  */

static struct image_keyword svg_format[SVG_LAST] =
{
  {":type",		IMAGE_SYMBOL_VALUE,			1},
  {":data",		IMAGE_STRING_VALUE,			0},
  {":file",		IMAGE_STRING_VALUE,			0},
  {":ascent",		IMAGE_ASCENT_VALUE,			0},
  {":margin",		IMAGE_POSITIVE_INTEGER_VALUE_OR_PAIR,	0},
  {":relief",		IMAGE_INTEGER_VALUE,			0},
  {":conversion",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":heuristic-mask",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":mask",		IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":background",	IMAGE_STRING_OR_NIL_VALUE,		0}
};

/* Structure describing the image type `svg'.  Its the same type of
   structure defined for all image formats, handled by emacs image functions.
   see struct image_type in dispextern.h
*/

static struct image_type svg_type =
{
  &Qsvg, /* an identifier showing that this is an image structure for the SVG format*/
  svg_image_p, /* handle to a function that can be used to identify a svg file*/
  svg_load, /* handle to function used to load a svg file*/
  x_clear_image,/* handle to function to free sresources for SVG*/
  NULL /* an internal field to link to the next image type in a list of image types, will be filled in when registering the format*/
};


/* Return non-zero if OBJECT is a valid SVG image specification.
   do this by calling parse_image_spec and supplying the keywords that identify the SVG format
 */

static int
svg_image_p (object)
     Lisp_Object object;
{
  struct image_keyword fmt[SVG_LAST];
  bcopy (svg_format, fmt, sizeof fmt);

  if (!parse_image_spec (object, fmt, SVG_LAST, Qsvg))
    return 0;

  /* Must specify either the :data or :file keyword.  */
  return fmt[SVG_FILE].count + fmt[SVG_DATA].count == 1;
}

#include <librsvg/rsvg.h>

/* DEF_IMGLIB_FN() here in the future.
this macro is used to handle loading of dynamic link library functions for various OS:es.
currently only librsvg2 is supportedd, which is only available for X, so its not strictly necessary yet.
The current code is thought to be compatible with this scheme because of the defines below, should librsvg2 become available on more plattforms.
*/

#define fn_rsvg_handle_new		rsvg_handle_new
#define fn_rsvg_handle_set_size_callback rsvg_handle_set_size_callback
#define fn_rsvg_handle_write		rsvg_handle_write
#define fn_rsvg_handle_close		rsvg_handle_close
#define fn_rsvg_handle_get_pixbuf	rsvg_handle_get_pixbuf
#define fn_rsvg_handle_free		rsvg_handle_free

#define fn_gdk_pixbuf_get_width		gdk_pixbuf_get_width
#define fn_gdk_pixbuf_get_height	gdk_pixbuf_get_height
#define fn_gdk_pixbuf_get_pixels	gdk_pixbuf_get_pixels
#define fn_gdk_pixbuf_get_rowstride	gdk_pixbuf_get_rowstride
#define fn_gdk_pixbuf_get_colorspace	gdk_pixbuf_get_colorspace
#define fn_gdk_pixbuf_get_n_channels	gdk_pixbuf_get_n_channels
#define fn_gdk_pixbuf_get_has_alpha	gdk_pixbuf_get_has_alpha
#define fn_gdk_pixbuf_get_bits_per_sample gdk_pixbuf_get_bits_per_sample


/* Load SVG image IMG for use on frame F.  Value is non-zero if
   successful. this function wil go into the svg_type structure, and
   the prototype thus needs to be compatible with that structure */

static int
svg_load (f, img)
     struct frame *f;
     struct image *img;
{
  int success_p = 0;
  Lisp_Object file_name;

  /* If IMG->spec specifies a file name, create a non-file spec from it.  */
  file_name = image_spec_value (img->spec, QCfile, NULL);
  if (STRINGP (file_name))
    {
      Lisp_Object file;
      unsigned char *contents;
      int size;
      struct gcpro gcpro1;

      file = x_find_image_file (file_name);
      GCPRO1 (file);
      if (!STRINGP (file))
      {
        image_error ("Cannot find image file `%s'", file_name, Qnil);
        UNGCPRO;
        return 0;
      }

      contents = slurp_file (SDATA (file), &size); /* read the entire file into memory*/
      if (contents == NULL)
      {
        image_error ("Error loading SVG image `%s'", img->spec, Qnil);
        UNGCPRO;
        return 0;
      }

      success_p = svg_load_image (f, img, contents, size); /* if the file was slurped into memory properly, parse it*/
      xfree (contents);
      UNGCPRO;
    }
  else/*its not a file, its a lisp object*/
    {
      Lisp_Object data;

      data = image_spec_value (img->spec, QCdata, NULL);
      success_p = svg_load_image (f, img, SDATA (data), SBYTES (data));
    }

  return success_p;
}

/* helper function for svg_load, does the actual loading
 given contents and size, apart from frame and image structures, passed from svg_load

 Uses librsvg to do most of the image processing.
 
 Returns non-zero when sucessful
*/
static int
svg_load_image (f, img, contents, size)
     struct frame *f;
     struct image *img;
     unsigned char *contents;
     unsigned int size;
{
  RsvgHandle *rsvg_handle;
  GError *error = NULL;
  GdkPixbuf *pixbuf;
  int width;
  int height;
  const guint8 *pixels;
  int rowstride;
  XImagePtr ximg;
  XColor background;
  int x;
  int y;

  g_type_init (); /*glib function that must be called prior to using gnome type library functions*/
  rsvg_handle = fn_rsvg_handle_new ();/* make a handle to a new rsvg object*/

  fn_rsvg_handle_write (rsvg_handle, contents, size, &error);/*parse "contents" and fill in the rsvg_handle*/
  if (error)
    goto rsvg_error;

  fn_rsvg_handle_close (rsvg_handle, &error);/*the parsing is complete, rsvg_handle is ready to use*/
  if (error)
    goto rsvg_error;

  pixbuf = fn_rsvg_handle_get_pixbuf (rsvg_handle);/* we can now get a valid pixel buffer from the svg file, if all went ok*/
  eassert (pixbuf);

  /* extract some meta data from he svg handle*/
  width     = fn_gdk_pixbuf_get_width (pixbuf);
  height    = fn_gdk_pixbuf_get_height (pixbuf);
  pixels    = fn_gdk_pixbuf_get_pixels (pixbuf);
  rowstride = fn_gdk_pixbuf_get_rowstride (pixbuf);

  /*validate the svg meta data*/
  eassert (fn_gdk_pixbuf_get_colorspace (pixbuf) == GDK_COLORSPACE_RGB);
  eassert (fn_gdk_pixbuf_get_n_channels (pixbuf) == 4);
  eassert (fn_gdk_pixbuf_get_has_alpha (pixbuf));
  eassert (fn_gdk_pixbuf_get_bits_per_sample (pixbuf) == 8);

  /* try to create a x pixmap to hold the svg pixmap*/
  if (!x_create_x_image_and_pixmap (f, width, height, 0, &ximg, &img->pixmap)) {
    g_object_unref (pixbuf);
    return 0;
  }

  init_color_table ();

#ifdef HAVE_X_WINDOWS

  background.pixel = FRAME_BACKGROUND_PIXEL (f);
  x_query_color (f, &background);

  /* svg pixmaps specify transparency in the last byte, so right shift 8 bits to get rid of it, since emacs doesnt support transparency*/
  background.red   >>= 8;
  background.green >>= 8;
  background.blue  >>= 8;

#else /* not HAVE_X_WINDOWS */
#error FIXME
#endif

  /* this loop handles opacity values, since emacs assumes
     non-transparent images.  Each pixel must be "flattened" by
     calculating he resulting color, given the transparency of the
     pixel, and the image background color.
   */
  for (y = 0; y < height; ++y)
    {
      for (x = 0; x < width; ++x)
	{
	  unsigned red;
	  unsigned green;
	  unsigned blue;
	  unsigned opacity;

	  red     = *pixels++;
	  green   = *pixels++;
	  blue    = *pixels++;
	  opacity = *pixels++;

	  red   = ((red * opacity)
		   + (background.red * ((1 << 8) - opacity)));
	  green = ((green * opacity)
		   + (background.green * ((1 << 8) - opacity)));
	  blue  = ((blue * opacity)
		   + (background.blue * ((1 << 8) - opacity)));

	  XPutPixel (ximg, x, y, lookup_rgb_color (f, red, green, blue));
	}

      pixels += rowstride - 4 * width;
    }

#ifdef COLOR_TABLE_SUPPORT
  /* Remember colors allocated for this image.  */
  img->colors = colors_in_color_table (&img->ncolors);
  free_color_table ();
#endif /* COLOR_TABLE_SUPPORT */

  g_object_unref (pixbuf);

  /* Put the image into the pixmap, then free the X image and its buffer. */
  x_put_x_image (f, ximg, img->pixmap, width, height);
  x_destroy_x_image (ximg);

  img->width  = width;
  img->height = height;

  return 1;

 rsvg_error:
  /* FIXME: Use error->message. */
  image_error ("Error parsing SVG image `%s'", img->spec, Qnil);
  g_error_free (error);
  return 0;
}

#endif	/* defined (HAVE_RSVG) */



-- 
Joakim Verona

Re: SVG support(again) ?

[Richard Stallman]

You're getting closer.  There are enough comments now,
but they need to be formatted cleanly and consistently with the
rest of Emacs.

    /* DEF_IMGLIB_FN() here in the future.

Do you mean

    /* TO DO: use DEF_IMGLIB_FN here.

It is vital to use words like "TO DO:" and "use",
because following such patterns makes the meaning clear.

(In GNU we don't write `()' after a function name.)

Aside from that, it will be clean if you fill the comment lines
to 70 character width.

Also, please use two spaces at the end of a sentence,
and please put a period and two spaces at the end of every comment
that contents sentences.

    /* Load SVG image IMG for use on frame F.  Value is non-zero if
       successful. this function wil go into the svg_type structure, and
       the prototype thus needs to be compatible with that structure */

should be

    /* Load SVG image IMG for use on frame F.  Value is non-zero if
       successful.  This function will go into the svg_type structure, and
       the prototype, so it needs to be compatible with that structure.  */


	  contents = slurp_file (SDATA (file), &size); /* read the entire file into memory*/

That style makes lines wide and hard to read, so please put the comment
on a separate line.  It should start with a capital letter, and end
with a period and two spaces.

          /* Read the entire file into memory.  */
	  contents = slurp_file (SDATA (file), &size);


    /* helper function for svg_load, does the actual loading
     given contents and size, apart from frame and image structures, passed from svg_load

     Uses librsvg to do most of the image processing.

     Returns non-zero when sucessful
    */

This should explain each of the arguments by name.
Please also start it with a capital letter, and end it with a period,
and avoid lines that are too long.

Re: SVG support(again) ?

[joakim]

Richard Stallman <rms@gnu.org> writes:

> You're getting closer.  There are enough comments now,
> but they need to be formatted cleanly and consistently with the
> rest of Emacs.
>
>     /* DEF_IMGLIB_FN() here in the future.
>
> Do you mean
>
>     /* TO DO: use DEF_IMGLIB_FN here.
>
> It is vital to use words like "TO DO:" and "use",
> because following such patterns makes the meaning clear.
>
> (In GNU we don't write `()' after a function name.)
>
> Aside from that, it will be clean if you fill the comment lines
> to 70 character width.
>
> Also, please use two spaces at the end of a sentence,
> and please put a period and two spaces at the end of every comment
> that contents sentences.
>
>     /* Load SVG image IMG for use on frame F.  Value is non-zero if
>        successful. this function wil go into the svg_type structure, and
>        the prototype thus needs to be compatible with that structure */
>
> should be
>
>     /* Load SVG image IMG for use on frame F.  Value is non-zero if
>        successful.  This function will go into the svg_type structure, and
>        the prototype, so it needs to be compatible with that structure.  */
>
>
> 	  contents = slurp_file (SDATA (file), &size); /* read the entire file into memory*/
>
> That style makes lines wide and hard to read, so please put the comment
> on a separate line.  It should start with a capital letter, and end
> with a period and two spaces.
>
>           /* Read the entire file into memory.  */
> 	  contents = slurp_file (SDATA (file), &size);
>
>
>     /* helper function for svg_load, does the actual loading
>      given contents and size, apart from frame and image structures, passed from svg_load
>
>      Uses librsvg to do most of the image processing.
>
>      Returns non-zero when sucessful
>     */
>
> This should explain each of the arguments by name.
> Please also start it with a capital letter, and end it with a period,
> and avoid lines that are too long.

Ok, this is the next iteration. Thanks for your patience!


/***********************************************************************
				 SVG
 ***********************************************************************/

#if defined (HAVE_RSVG)

/* Function prototypes.  */

static int svg_image_p P_ ((Lisp_Object object));
static int svg_load P_ ((struct frame *f, struct image *img));

static int svg_load_image P_ ((struct frame *, struct image *,
			       unsigned char *, unsigned int));

/* The symbol `svg' identifying images of this type. */

Lisp_Object Qsvg;

/* Indices of image specification fields in svg_format, below.  */

enum svg_keyword_index
{
  SVG_TYPE,
  SVG_DATA,
  SVG_FILE,
  SVG_ASCENT,
  SVG_MARGIN,
  SVG_RELIEF,
  SVG_ALGORITHM,
  SVG_HEURISTIC_MASK,
  SVG_MASK,
  SVG_BACKGROUND,
  SVG_LAST
};

/* Vector of image_keyword structures describing the format
   of valid user-defined image specifications.  */

static struct image_keyword svg_format[SVG_LAST] =
{
  {":type",		IMAGE_SYMBOL_VALUE,			1},
  {":data",		IMAGE_STRING_VALUE,			0},
  {":file",		IMAGE_STRING_VALUE,			0},
  {":ascent",		IMAGE_ASCENT_VALUE,			0},
  {":margin",		IMAGE_POSITIVE_INTEGER_VALUE_OR_PAIR,	0},
  {":relief",		IMAGE_INTEGER_VALUE,			0},
  {":conversion",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":heuristic-mask",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":mask",		IMAGE_DONT_CHECK_VALUE_TYPE,		0},
  {":background",	IMAGE_STRING_OR_NIL_VALUE,		0}
};

/* Structure describing the image type `svg'.  Its the same type of
   structure defined for all image formats, handled by emacs image
   functions.  See struct image_type in dispextern.h.  */

static struct image_type svg_type =
{
  /* An identifier showing that this is an image structure for the SVG format.  */
  &Qsvg,
  /* Handle to a function that can be used to identify a SVG file.  */
  svg_image_p,
  /* Handle to function used to load a SVG file.  */
  svg_load,
  /* Handle to function to free sresources for SVG.  */
  x_clear_image,
  /* An internal field to link to the next image type in a list of
     image types, will be filled in when registering the format.  */
  NULL  
};


/* Return non-zero if OBJECT is a valid SVG image specification.  Do
   this by calling parse_image_spec and supplying the keywords that
   identify the SVG format.   */

static int
svg_image_p (object)
     Lisp_Object object;
{
  struct image_keyword fmt[SVG_LAST];
  bcopy (svg_format, fmt, sizeof fmt);

  if (!parse_image_spec (object, fmt, SVG_LAST, Qsvg))
    return 0;

  /* Must specify either the :data or :file keyword.  */
  return fmt[SVG_FILE].count + fmt[SVG_DATA].count == 1;
}

#include <librsvg/rsvg.h>

/* TO DO: define DEF_IMGLIB_FN here.  This macro is used to handle
loading of dynamic link library functions for various OS:es.
Currently only librsvg2 is supported, which is only available for X,
so its not strictly necessary yet.  The current code is thought to be
compatible with this scheme because of the defines below, should
librsvg2 become available on more plattforms.  */

#define fn_rsvg_handle_new		rsvg_handle_new
#define fn_rsvg_handle_set_size_callback rsvg_handle_set_size_callback
#define fn_rsvg_handle_write		rsvg_handle_write
#define fn_rsvg_handle_close		rsvg_handle_close
#define fn_rsvg_handle_get_pixbuf	rsvg_handle_get_pixbuf
#define fn_rsvg_handle_free		rsvg_handle_free

#define fn_gdk_pixbuf_get_width		gdk_pixbuf_get_width
#define fn_gdk_pixbuf_get_height	gdk_pixbuf_get_height
#define fn_gdk_pixbuf_get_pixels	gdk_pixbuf_get_pixels
#define fn_gdk_pixbuf_get_rowstride	gdk_pixbuf_get_rowstride
#define fn_gdk_pixbuf_get_colorspace	gdk_pixbuf_get_colorspace
#define fn_gdk_pixbuf_get_n_channels	gdk_pixbuf_get_n_channels
#define fn_gdk_pixbuf_get_has_alpha	gdk_pixbuf_get_has_alpha
#define fn_gdk_pixbuf_get_bits_per_sample gdk_pixbuf_get_bits_per_sample


/* Load SVG image IMG for use on frame F.  Value is non-zero if
   successful. this function will go into the svg_type structure, and
   the prototype thus needs to be compatible with that structure.  */

static int
svg_load (f, img)
     struct frame *f;
     struct image *img;
{
  int success_p = 0;
  Lisp_Object file_name;

  /* If IMG->spec specifies a file name, create a non-file spec from it.  */
  file_name = image_spec_value (img->spec, QCfile, NULL);
  if (STRINGP (file_name))
    {
      Lisp_Object file;
      unsigned char *contents;
      int size;
      struct gcpro gcpro1;

      file = x_find_image_file (file_name);
      GCPRO1 (file);
      if (!STRINGP (file))
      {
        image_error ("Cannot find image file `%s'", file_name, Qnil);
        UNGCPRO;
        return 0;
      }
      
      /* Read the entire file into memory.  */
      contents = slurp_file (SDATA (file), &size);
      if (contents == NULL)
      {
        image_error ("Error loading SVG image `%s'", img->spec, Qnil);
        UNGCPRO;
        return 0;
      }
      /* If the file was slurped into memory properly, parse it.  */
      success_p = svg_load_image (f, img, contents, size); 
      xfree (contents);
      UNGCPRO;
    }
  /* Else its not a file, its a lisp object.  Load the image from a
     lisp object rather than a file.  */
  else
    {
      Lisp_Object data;

      data = image_spec_value (img->spec, QCdata, NULL);
      success_p = svg_load_image (f, img, SDATA (data), SBYTES (data));
    }

  return success_p;
}

/* svg_load_image is a helper function for svg_load, which does the actual
 loading given contents and size, apart from frame and image
 structures, passed from svg_load.

 Uses librsvg to do most of the image processing.
 
 Returns non-zero when sucessful.  */
static int
svg_load_image (f, img, contents, size)
    /* Pointer to emacs frame sturcture.  */
     struct frame *f;
     /* Pointer to emacs image structure.  */
     struct image *img;
     /* String containing the SVG XML data to be parsed.  */
     unsigned char *contents;
     /* Size of data in bytes.  */
     unsigned int size;
{
  RsvgHandle *rsvg_handle;
  GError *error = NULL;
  GdkPixbuf *pixbuf;
  int width;
  int height;
  const guint8 *pixels;
  int rowstride;
  XImagePtr ximg;
  XColor background;
  int x;
  int y;

  /* g_type_init is a glib function that must be called prior to using
     gnome type library functions.  */
  g_type_init ();
  /* Make a handle to a new rsvg object.  */
  rsvg_handle = fn_rsvg_handle_new ();

  /* Parse the contents argument and fill in the rsvg_handle.  */
  fn_rsvg_handle_write (rsvg_handle, contents, size, &error);
  if (error)
    goto rsvg_error;

  /* The parsing is complete, rsvg_handle is ready to used, close it
     for further writes.  */
  fn_rsvg_handle_close (rsvg_handle, &error);
  if (error)
    goto rsvg_error;
  /* We can now get a valid pixel buffer from the svg file, if all
     went ok.  */
  pixbuf = fn_rsvg_handle_get_pixbuf (rsvg_handle);
  eassert (pixbuf);

  /* Extract some meta data from the svg handle.  */
  width     = fn_gdk_pixbuf_get_width (pixbuf);
  height    = fn_gdk_pixbuf_get_height (pixbuf);
  pixels    = fn_gdk_pixbuf_get_pixels (pixbuf);
  rowstride = fn_gdk_pixbuf_get_rowstride (pixbuf);

  /* Validate the svg meta data.  */
  eassert (fn_gdk_pixbuf_get_colorspace (pixbuf) == GDK_COLORSPACE_RGB);
  eassert (fn_gdk_pixbuf_get_n_channels (pixbuf) == 4);
  eassert (fn_gdk_pixbuf_get_has_alpha (pixbuf));
  eassert (fn_gdk_pixbuf_get_bits_per_sample (pixbuf) == 8);

  /* Try to create a x pixmap to hold the svg pixmap.  */
  if (!x_create_x_image_and_pixmap (f, width, height, 0, &ximg, &img->pixmap)) {
    g_object_unref (pixbuf);
    return 0;
  }

  init_color_table ();

  /* TODO: The code is somewhat prepared for other environments than
     X, but is far from done.  */
#ifdef HAVE_X_WINDOWS

  background.pixel = FRAME_BACKGROUND_PIXEL (f);
  x_query_color (f, &background);

  /* SVG pixmaps specify transparency in the last byte, so right shift
     8 bits to get rid of it, since emacs doesnt support
     transparency.  */
  background.red   >>= 8;
  background.green >>= 8;
  background.blue  >>= 8;

#else /* not HAVE_X_WINDOWS */
#error FIXME
#endif

  /* This loop handles opacity values, since Emacs assumes
     non-transparent images.  Each pixel must be "flattened" by
     calculating he resulting color, given the transparency of the
     pixel, and the image background color.   */
  for (y = 0; y < height; ++y)
    {
      for (x = 0; x < width; ++x)
	{
	  unsigned red;
	  unsigned green;
	  unsigned blue;
	  unsigned opacity;

	  red     = *pixels++;
	  green   = *pixels++;
	  blue    = *pixels++;
	  opacity = *pixels++;

	  red   = ((red * opacity)
		   + (background.red * ((1 << 8) - opacity)));
	  green = ((green * opacity)
		   + (background.green * ((1 << 8) - opacity)));
	  blue  = ((blue * opacity)
		   + (background.blue * ((1 << 8) - opacity)));

	  XPutPixel (ximg, x, y, lookup_rgb_color (f, red, green, blue));
	}

      pixels += rowstride - 4 * width;
    }

#ifdef COLOR_TABLE_SUPPORT
  /* Remember colors allocated for this image.  */
  img->colors = colors_in_color_table (&img->ncolors);
  free_color_table ();
#endif /* COLOR_TABLE_SUPPORT */

  g_object_unref (pixbuf);

  /* Put the image into the pixmap, then free the X image and its
     buffer.  */
  x_put_x_image (f, ximg, img->pixmap, width, height);
  x_destroy_x_image (ximg);

  img->width  = width;
  img->height = height;

  return 1;

 rsvg_error:
  /* FIXME: Use error->message so the user knows what is the actual
     problem with the image.  */
  image_error ("Error parsing SVG image `%s'", img->spec, Qnil);
  g_error_free (error);
  return 0;
}

#endif	/* defined (HAVE_RSVG) */

-- 
Joakim Verona

Re: SVG support(again) ?

[Richard Stallman]

The code is now ready for installation.  Thank you.
To install it requires a change log entry, and a NEWS entry.

Re: SVG support(again) ?

[joakim]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Richard Stallman <rms@gnu.org> writes:

> The code is now ready for installation.  Thank you.
> To install it requires a change log entry, and a NEWS entry.

Ok, heres a new version of the patch, and a NEWS entry that was agreed
upon earlier. I suppose the committer provides a changelog entry?
Please remember that Paul Pogonyshev is the author of the patch, I've
just cleaned it up a bit.


NEWS entry:

    ** Support for SVG images

    Emacs now supports the SVG image format through librsvg2.

Patch:    


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: svg.patch --]
[-- Type: text/x-patch, Size: 16687 bytes --]

? emacs_svg.patch
Index: configure.in
===================================================================
RCS file: /sources/emacs/emacs/configure.in,v
retrieving revision 1.459
diff -u -p -r1.459 configure.in
--- configure.in	26 Jul 2007 05:26:01 -0000	1.459
+++ configure.in	20 Aug 2007 08:47:43 -0000
@@ -110,10 +110,12 @@ AC_ARG_WITH(png,
 [  --with-png              use -lpng for displaying PNG images])
 AC_ARG_WITH(gpm,
 [  --with-gpm              use -lgpm for mouse support on a GNU/Linux console])
+AC_ARG_WITH(rsvg,
+[  --with-rsvg             use -lrsvg-2 for displaying SVG images])
 AC_ARG_WITH(gtk,
 [  --with-gtk              use GTK (same as --with-x-toolkit=gtk)])
 AC_ARG_WITH(pkg-config-prog,
-[  --with-pkg-config-prog  Path to pkg-config to use for finding GTK])
+[  --with-pkg-config-prog  Path to pkg-config to use for finding GTK and librsvg])
 AC_ARG_WITH(toolkit-scroll-bars,
 [  --without-toolkit-scroll-bars
                           don't use Motif or Xaw3d scroll bars])
@@ -2122,6 +2124,32 @@ fail;
   fi
 fi
 
+### Use -lrsvg-2 if available, unless `--with-rsvg=no' is specified.
+HAVE_RSVG=no
+if test "${HAVE_X11}" = "yes"; then
+  if test "${with_rsvg}" != "no"; then
+    dnl Check if `--with-pkg-config-prog' has been given.
+    if test "X${with_pkg_config_prog}" != X; then
+      PKG_CONFIG="${with_pkg_config_prog}"
+    fi
+
+    RSVG_REQUIRED=2.0.0
+    RSVG_MODULE="librsvg-2.0 >= $RSVG_REQUIRED"
+
+    PKG_CHECK_MODULES(RSVG, $RSVG_MODULE, :, :)
+    AC_SUBST(RSVG_CFLAGS)
+    AC_SUBST(RSVG_LIBS)
+
+    if test ".${RSVG_CFLAGS}" != "."; then
+      HAVE_RSVG=yes
+      AC_DEFINE(HAVE_RSVG, 1, [Define to 1 if using librsvg.])
+      CFLAGS="$CFLAGS $RSVG_CFLAGS"
+      LIBS="$RSVG_LIBS $LIBS"
+    fi
+  fi
+fi
+
+
 HAVE_GTK=no
 if test "${with_gtk}" = "yes" && test "$USE_X_TOOLKIT" = "gtk"; then
   USE_X_TOOLKIT=none
@@ -3362,6 +3390,7 @@ echo "  Does Emacs use -ljpeg?          
 echo "  Does Emacs use -ltiff?                                  ${HAVE_TIFF}"
 echo "  Does Emacs use a gif library?                           ${HAVE_GIF} $ac_gif_lib_name"
 echo "  Does Emacs use -lpng?                                   ${HAVE_PNG}"
+echo "  Does Emacs use -lrsvg-2?                                ${HAVE_RSVG}"
 echo "  Does Emacs use -lgpm?                                   ${HAVE_GPM}"
 echo "  Does Emacs use X toolkit scroll bars?                   ${USE_TOOLKIT_SCROLL_BARS}"
 echo
Index: lisp/image-file.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/image-file.el,v
retrieving revision 1.29
diff -u -p -r1.29 image-file.el
--- lisp/image-file.el	26 Jul 2007 05:26:26 -0000	1.29
+++ lisp/image-file.el	20 Aug 2007 08:48:30 -0000
@@ -39,7 +39,7 @@
 
 ;;;###autoload
 (defcustom image-file-name-extensions
-  '("png" "jpeg" "jpg" "gif" "tiff" "tif" "xbm" "xpm" "pbm" "pgm" "ppm" "pnm")
+  '("png" "jpeg" "jpg" "gif" "tiff" "tif" "xbm" "xpm" "pbm" "pgm" "ppm" "pnm" "svg")
   "*A list of image-file filename extensions.
 Filenames having one of these extensions are considered image files,
 in addition to those matching `image-file-name-regexps'.
Index: lisp/image.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/image.el,v
retrieving revision 1.72
diff -u -p -r1.72 image.el
--- lisp/image.el	26 Jul 2007 05:26:26 -0000	1.72
+++ lisp/image.el	20 Aug 2007 08:48:30 -0000
@@ -43,7 +43,8 @@
 static char \\1_bits" . xbm)
     ("\\`\\(?:MM\0\\*\\|II\\*\0\\)" . tiff)
     ("\\`[\t\n\r ]*%!PS" . postscript)
-    ("\\`\xff\xd8" . (image-jpeg-p . jpeg)))
+    ("\\`\xff\xd8" . (image-jpeg-p . jpeg))
+    ("\\`<\\?xml " . svg))
   "Alist of (REGEXP . IMAGE-TYPE) pairs used to auto-detect image types.
 When the first bytes of an image file match REGEXP, it is assumed to
 be of image type IMAGE-TYPE if IMAGE-TYPE is a symbol.  If not a symbol,
Index: src/Makefile.in
===================================================================
RCS file: /sources/emacs/emacs/src/Makefile.in,v
retrieving revision 1.346
diff -u -p -r1.346 Makefile.in
--- src/Makefile.in	26 Jul 2007 05:27:47 -0000	1.346
+++ src/Makefile.in	20 Aug 2007 08:49:46 -0000
@@ -281,7 +281,7 @@ TOOLKIT_DEFINES =
 
 /* C_SWITCH_X_SITE must come before C_SWITCH_X_MACHINE and C_SWITCH_X_SYSTEM
    since it may have -I options that should override those two.  */
-ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} C_SWITCH_MACHINE C_SWITCH_SYSTEM C_SWITCH_SITE C_SWITCH_X_SITE C_SWITCH_X_MACHINE C_SWITCH_X_SYSTEM C_SWITCH_SYSTEM_TEMACS ${CFLAGS_SOUND} ${CFLAGS}
+ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} C_SWITCH_MACHINE C_SWITCH_SYSTEM C_SWITCH_SITE @RSVG_CFLAGS@ C_SWITCH_X_SITE C_SWITCH_X_MACHINE C_SWITCH_X_SYSTEM C_SWITCH_SYSTEM_TEMACS ${CFLAGS_SOUND} ${CFLAGS}
 .c.o:
 	$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
 
@@ -450,7 +450,7 @@ XFT_LIBS=@XFT_LIBS@
 /* LD_SWITCH_X_DEFAULT comes after everything else that specifies
    options for where to find X libraries, but before those libraries.  */
 X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
-LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM $(XFT_LIBS)
+LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM @RSVG_LIBS@ LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM $(XFT_LIBS)
 #else /* not HAVE_X11 */
 LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM
 #endif /* not HAVE_X11 */
Index: src/image.c
===================================================================
RCS file: /sources/emacs/emacs/src/image.c,v
retrieving revision 1.77
diff -u -p -r1.77 image.c
--- src/image.c	7 Aug 2007 16:25:26 -0000	1.77
+++ src/image.c	20 Aug 2007 08:49:50 -0000
@@ -8199,6 +8199,329 @@ gif_load (f, img)
 #endif /* HAVE_GIF */
 
 
+ 
+/***********************************************************************
+				 SVG
+ ***********************************************************************/
+
+#if defined (HAVE_RSVG)
+
+/* Function prototypes.  */
+
+static int svg_image_p P_ ((Lisp_Object object));
+static int svg_load P_ ((struct frame *f, struct image *img));
+
+static int svg_load_image P_ ((struct frame *, struct image *,
+			       unsigned char *, unsigned int));
+
+/* The symbol `svg' identifying images of this type. */
+
+Lisp_Object Qsvg;
+
+/* Indices of image specification fields in svg_format, below.  */
+
+enum svg_keyword_index
+{
+  SVG_TYPE,
+  SVG_DATA,
+  SVG_FILE,
+  SVG_ASCENT,
+  SVG_MARGIN,
+  SVG_RELIEF,
+  SVG_ALGORITHM,
+  SVG_HEURISTIC_MASK,
+  SVG_MASK,
+  SVG_BACKGROUND,
+  SVG_LAST
+};
+
+/* Vector of image_keyword structures describing the format
+   of valid user-defined image specifications.  */
+
+static struct image_keyword svg_format[SVG_LAST] =
+{
+  {":type",		IMAGE_SYMBOL_VALUE,			1},
+  {":data",		IMAGE_STRING_VALUE,			0},
+  {":file",		IMAGE_STRING_VALUE,			0},
+  {":ascent",		IMAGE_ASCENT_VALUE,			0},
+  {":margin",		IMAGE_POSITIVE_INTEGER_VALUE_OR_PAIR,	0},
+  {":relief",		IMAGE_INTEGER_VALUE,			0},
+  {":conversion",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
+  {":heuristic-mask",	IMAGE_DONT_CHECK_VALUE_TYPE,		0},
+  {":mask",		IMAGE_DONT_CHECK_VALUE_TYPE,		0},
+  {":background",	IMAGE_STRING_OR_NIL_VALUE,		0}
+};
+
+/* Structure describing the image type `svg'.  Its the same type of
+   structure defined for all image formats, handled by emacs image
+   functions.  See struct image_type in dispextern.h.  */
+
+static struct image_type svg_type =
+{
+  /* An identifier showing that this is an image structure for the SVG format.  */
+  &Qsvg,
+  /* Handle to a function that can be used to identify a SVG file.  */
+  svg_image_p,
+  /* Handle to function used to load a SVG file.  */
+  svg_load,
+  /* Handle to function to free sresources for SVG.  */
+  x_clear_image,
+  /* An internal field to link to the next image type in a list of
+     image types, will be filled in when registering the format.  */
+  NULL  
+};
+
+
+/* Return non-zero if OBJECT is a valid SVG image specification.  Do
+   this by calling parse_image_spec and supplying the keywords that
+   identify the SVG format.   */
+
+static int
+svg_image_p (object)
+     Lisp_Object object;
+{
+  struct image_keyword fmt[SVG_LAST];
+  bcopy (svg_format, fmt, sizeof fmt);
+
+  if (!parse_image_spec (object, fmt, SVG_LAST, Qsvg))
+    return 0;
+
+  /* Must specify either the :data or :file keyword.  */
+  return fmt[SVG_FILE].count + fmt[SVG_DATA].count == 1;
+}
+
+#include <librsvg/rsvg.h>
+
+/* TO DO: define DEF_IMGLIB_FN here.  This macro is used to handle
+loading of dynamic link library functions for various OS:es.
+Currently only librsvg2 is supported, which is only available for X,
+so its not strictly necessary yet.  The current code is thought to be
+compatible with this scheme because of the defines below, should
+librsvg2 become available on more plattforms.  */
+
+#define fn_rsvg_handle_new		rsvg_handle_new
+#define fn_rsvg_handle_set_size_callback rsvg_handle_set_size_callback
+#define fn_rsvg_handle_write		rsvg_handle_write
+#define fn_rsvg_handle_close		rsvg_handle_close
+#define fn_rsvg_handle_get_pixbuf	rsvg_handle_get_pixbuf
+#define fn_rsvg_handle_free		rsvg_handle_free
+
+#define fn_gdk_pixbuf_get_width		gdk_pixbuf_get_width
+#define fn_gdk_pixbuf_get_height	gdk_pixbuf_get_height
+#define fn_gdk_pixbuf_get_pixels	gdk_pixbuf_get_pixels
+#define fn_gdk_pixbuf_get_rowstride	gdk_pixbuf_get_rowstride
+#define fn_gdk_pixbuf_get_colorspace	gdk_pixbuf_get_colorspace
+#define fn_gdk_pixbuf_get_n_channels	gdk_pixbuf_get_n_channels
+#define fn_gdk_pixbuf_get_has_alpha	gdk_pixbuf_get_has_alpha
+#define fn_gdk_pixbuf_get_bits_per_sample gdk_pixbuf_get_bits_per_sample
+
+
+/* Load SVG image IMG for use on frame F.  Value is non-zero if
+   successful. this function will go into the svg_type structure, and
+   the prototype thus needs to be compatible with that structure.  */
+
+static int
+svg_load (f, img)
+     struct frame *f;
+     struct image *img;
+{
+  int success_p = 0;
+  Lisp_Object file_name;
+
+  /* If IMG->spec specifies a file name, create a non-file spec from it.  */
+  file_name = image_spec_value (img->spec, QCfile, NULL);
+  if (STRINGP (file_name))
+    {
+      Lisp_Object file;
+      unsigned char *contents;
+      int size;
+      struct gcpro gcpro1;
+
+      file = x_find_image_file (file_name);
+      GCPRO1 (file);
+      if (!STRINGP (file))
+      {
+        image_error ("Cannot find image file `%s'", file_name, Qnil);
+        UNGCPRO;
+        return 0;
+      }
+      
+      /* Read the entire file into memory.  */
+      contents = slurp_file (SDATA (file), &size);
+      if (contents == NULL)
+      {
+        image_error ("Error loading SVG image `%s'", img->spec, Qnil);
+        UNGCPRO;
+        return 0;
+      }
+      /* If the file was slurped into memory properly, parse it.  */
+      success_p = svg_load_image (f, img, contents, size); 
+      xfree (contents);
+      UNGCPRO;
+    }
+  /* Else its not a file, its a lisp object.  Load the image from a
+     lisp object rather than a file.  */
+  else
+    {
+      Lisp_Object data;
+
+      data = image_spec_value (img->spec, QCdata, NULL);
+      success_p = svg_load_image (f, img, SDATA (data), SBYTES (data));
+    }
+
+  return success_p;
+}
+
+/* svg_load_image is a helper function for svg_load, which does the actual
+ loading given contents and size, apart from frame and image
+ structures, passed from svg_load.
+
+ Uses librsvg to do most of the image processing.
+ 
+ Returns non-zero when sucessful.  */
+static int
+svg_load_image (f, img, contents, size)
+    /* Pointer to emacs frame sturcture.  */
+     struct frame *f;
+     /* Pointer to emacs image structure.  */
+     struct image *img;
+     /* String containing the SVG XML data to be parsed.  */
+     unsigned char *contents;
+     /* Size of data in bytes.  */
+     unsigned int size;
+{
+  RsvgHandle *rsvg_handle;
+  GError *error = NULL;
+  GdkPixbuf *pixbuf;
+  int width;
+  int height;
+  const guint8 *pixels;
+  int rowstride;
+  XImagePtr ximg;
+  XColor background;
+  int x;
+  int y;
+
+  /* g_type_init is a glib function that must be called prior to using
+     gnome type library functions.  */
+  g_type_init ();
+  /* Make a handle to a new rsvg object.  */
+  rsvg_handle = fn_rsvg_handle_new ();
+
+  /* Parse the contents argument and fill in the rsvg_handle.  */
+  fn_rsvg_handle_write (rsvg_handle, contents, size, &error);
+  if (error)
+    goto rsvg_error;
+
+  /* The parsing is complete, rsvg_handle is ready to used, close it
+     for further writes.  */
+  fn_rsvg_handle_close (rsvg_handle, &error);
+  if (error)
+    goto rsvg_error;
+  /* We can now get a valid pixel buffer from the svg file, if all
+     went ok.  */
+  pixbuf = fn_rsvg_handle_get_pixbuf (rsvg_handle);
+  eassert (pixbuf);
+
+  /* Extract some meta data from the svg handle.  */
+  width     = fn_gdk_pixbuf_get_width (pixbuf);
+  height    = fn_gdk_pixbuf_get_height (pixbuf);
+  pixels    = fn_gdk_pixbuf_get_pixels (pixbuf);
+  rowstride = fn_gdk_pixbuf_get_rowstride (pixbuf);
+
+  /* Validate the svg meta data.  */
+  eassert (fn_gdk_pixbuf_get_colorspace (pixbuf) == GDK_COLORSPACE_RGB);
+  eassert (fn_gdk_pixbuf_get_n_channels (pixbuf) == 4);
+  eassert (fn_gdk_pixbuf_get_has_alpha (pixbuf));
+  eassert (fn_gdk_pixbuf_get_bits_per_sample (pixbuf) == 8);
+
+  /* Try to create a x pixmap to hold the svg pixmap.  */
+  if (!x_create_x_image_and_pixmap (f, width, height, 0, &ximg, &img->pixmap)) {
+    g_object_unref (pixbuf);
+    return 0;
+  }
+
+  init_color_table ();
+
+  /* TODO: The code is somewhat prepared for other environments than
+     X, but is far from done.  */
+#ifdef HAVE_X_WINDOWS
+
+  background.pixel = FRAME_BACKGROUND_PIXEL (f);
+  x_query_color (f, &background);
+
+  /* SVG pixmaps specify transparency in the last byte, so right shift
+     8 bits to get rid of it, since emacs doesnt support
+     transparency.  */
+  background.red   >>= 8;
+  background.green >>= 8;
+  background.blue  >>= 8;
+
+#else /* not HAVE_X_WINDOWS */
+#error FIXME
+#endif
+
+  /* This loop handles opacity values, since Emacs assumes
+     non-transparent images.  Each pixel must be "flattened" by
+     calculating he resulting color, given the transparency of the
+     pixel, and the image background color.   */
+  for (y = 0; y < height; ++y)
+    {
+      for (x = 0; x < width; ++x)
+	{
+	  unsigned red;
+	  unsigned green;
+	  unsigned blue;
+	  unsigned opacity;
+
+	  red     = *pixels++;
+	  green   = *pixels++;
+	  blue    = *pixels++;
+	  opacity = *pixels++;
+
+	  red   = ((red * opacity)
+		   + (background.red * ((1 << 8) - opacity)));
+	  green = ((green * opacity)
+		   + (background.green * ((1 << 8) - opacity)));
+	  blue  = ((blue * opacity)
+		   + (background.blue * ((1 << 8) - opacity)));
+
+	  XPutPixel (ximg, x, y, lookup_rgb_color (f, red, green, blue));
+	}
+
+      pixels += rowstride - 4 * width;
+    }
+
+#ifdef COLOR_TABLE_SUPPORT
+  /* Remember colors allocated for this image.  */
+  img->colors = colors_in_color_table (&img->ncolors);
+  free_color_table ();
+#endif /* COLOR_TABLE_SUPPORT */
+
+  g_object_unref (pixbuf);
+
+  /* Put the image into the pixmap, then free the X image and its
+     buffer.  */
+  x_put_x_image (f, ximg, img->pixmap, width, height);
+  x_destroy_x_image (ximg);
+
+  img->width  = width;
+  img->height = height;
+
+  return 1;
+
+ rsvg_error:
+  /* FIXME: Use error->message so the user knows what is the actual
+     problem with the image.  */
+  image_error ("Error parsing SVG image `%s'", img->spec, Qnil);
+  g_error_free (error);
+  return 0;
+}
+
+#endif	/* defined (HAVE_RSVG) */
+
+
+
 \f
 /***********************************************************************
 				Ghostscript
@@ -8591,6 +8914,11 @@ of `image-library-alist', which see).  *
     return CHECK_LIB_AVAILABLE (&png_type, init_png_functions, libraries);
 #endif
 
+#if defined (HAVE_RSVG)
+  if (EQ (type, Qsvg))
+    return CHECK_LIB_AVAILABLE (&svg_type, init_svg_functions, libraries);
+#endif
+  
 #ifdef HAVE_GHOSTSCRIPT
   if (EQ (type, Qpostscript))
     return CHECK_LIB_AVAILABLE (&gs_type, init_gs_functions, libraries);
@@ -8733,6 +9061,13 @@ non-numeric, there is no explicit limit 
   ADD_IMAGE_TYPE(Qpng);
 #endif
 
+#if defined (HAVE_RSVG)
+  Qsvg = intern ("svg");
+  staticpro (&Qsvg);
+  ADD_IMAGE_TYPE(Qsvg);
+#endif
+
+  
   defsubr (&Sinit_image_library);
   defsubr (&Sclear_image_cache);
   defsubr (&Simage_refresh);

[-- Attachment #3: Type: text/plain, Size: 20 bytes --]



-- 
Joakim Verona

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: SVG support(again) ?

[Richard Stallman]

    Ok, heres a new version of the patch, and a NEWS entry that was agreed
    upon earlier. I suppose the committer provides a changelog entry?
    Please remember that Paul Pogonyshev is the author of the patch, I've
    just cleaned it up a bit.

Can you please write the change log entry for it?
It should reflect the authorship, both yours and his.

Re: SVG support(again) ?

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     Ok, heres a new version of the patch, and a NEWS entry that was agreed
>     upon earlier. I suppose the committer provides a changelog entry?
>     Please remember that Paul Pogonyshev is the author of the patch, I've
>     just cleaned it up a bit.
>
> Can you please write the change log entry for it?
> It should reflect the authorship, both yours and his.

Ok, heres my attempt:

2007-08-21  Paul Pogonyshev  <pogonyshev@gmx.net>

	* configure.in, image-file.el, image.el,
        * Makefile.in, image.c: Support the SVG image file
        format through librsvg2. Some additional code somments
        where written by Joakim Verona <joakim@verona.se>.

-- 
Joakim Verona

Re: SVG support(again) ?

[Glenn Morris]

Thanks for this, I installed it. Let me know if I missed anything.

Re: SVG support(again) ?

[joakim]

Glenn Morris <rgm@gnu.org> writes:

> Thanks for this, I installed it. Let me know if I missed anything.

Great! That wasn't so hard. If theres some other low-level patches
needing cleanup before commiting, you can send them to me :)

-- 
Joakim Verona

svn icons in the toolbar (was: SVG support(again) ?)

[Leo]

Hi there,

Is it possible now to make the toolbar support svg or png icons? For png
support There is a patch in article: <1169151517.24488.17.camel@galahad>

Or you can obtain it from the archive:
http://permalink.gmane.org/gmane.emacs.devel/65285

On 2007-08-22 05:12 +0100, Glenn Morris wrote:
> Thanks for this, I installed it. Let me know if I missed anything.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

         Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> Hi there,
> 
> Is it possible now to make the toolbar support svg or png icons? For png
> support There is a patch in article: <1169151517.24488.17.camel@galahad>

That would be great.  It has been suggested that Emacs should use the new 
Gnome icons (http://people.freedesktop.org/~jimmac/).  It would be so much 
easier if we just could copy the png images.

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-08-30 06:08 +0100, Jan Djärv wrote:
> Leo skrev:
>> Hi there,
>>
>> Is it possible now to make the toolbar support svg or png icons? For png
>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>
> That would be great.  It has been suggested that Emacs should
> use the new Gnome icons
> (http://people.freedesktop.org/~jimmac/).  It would be so much
> easier if we just could copy the png images.
>
> 	Jan D.

Do you think the patch is good?

I have been using it since it was posted, so over 7 months now.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

         Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Richard Stallman]

    That would be great.  It has been suggested that Emacs should use the new 
    Gnome icons (http://people.freedesktop.org/~jimmac/).  It would be so much 
    easier if we just could copy the png images.

I think that would cause more trouble than it is worth, because not
all systems have development versions of png libraries installed (as I
recently found).

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
>> Leo skrev:
>>> Hi there,
>>>
>>> Is it possible now to make the toolbar support svg or png icons? For png
>>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>> That would be great.  It has been suggested that Emacs should
>> use the new Gnome icons
>> (http://people.freedesktop.org/~jimmac/).  It would be so much
>> easier if we just could copy the png images.
>>
>> 	Jan D.
> 
> Do you think the patch is good?
> 
> I have been using it since it was posted, so over 7 months now.
>

It looks good.  The comment

  + Currently, the function does not test for XPM support, only PNG.

is not needed AFAIK, xpm support is built in to Emacs without external libraries.

	Jan D.

Re: svn icons in the toolbar

[Benjamin Hawkes-Lewis]

Leo wrote:
> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
> 
> Do you think the patch is good?
> 
> I have been using it since it was posted, so over 7 months now.

Cool. I'm the patch author. The main problem with my patch is I haven't 
signed the FSF release forms because I lost them and kept imagining 
they'd turn up amongst my other papers. But they haven't resurfaced, and 
if FSF could kindly send me new forms, I will sign and return them, 
especially now that people are actually enjoying the patch. :)

--
Benjamin Hawkes-Lewis

Re: svn icons in the toolbar

[Leo]

On 2007-08-31 08:07 +0100, Benjamin Hawkes-Lewis wrote:
> Leo wrote:
>> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
>>
>> Do you think the patch is good?
>>
>> I have been using it since it was posted, so over 7 months now.
>
> Cool. I'm the patch author. The main problem with my patch is I
> haven't signed the FSF release forms because I lost them and
> kept imagining they'd turn up amongst my other papers. But they
> haven't resurfaced, and if FSF could kindly send me new forms, I
> will sign and return them, especially now that people are
> actually enjoying the patch. :)

Does that mean that RMS has already agreed to install the patch?

In that case, can someone tell FSF to send papers to Benjamin?

Thanks,
-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

         Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Leo]

On 2007-08-30 21:50 +0100, Richard Stallman wrote:
>     That would be great.  It has been suggested that Emacs should use the new 
>     Gnome icons (http://people.freedesktop.org/~jimmac/).  It would be so much 
>     easier if we just could copy the png images.
>
> I think that would cause more trouble than it is worth, because not
> all systems have development versions of png libraries installed (as I
> recently found).

I don't think there is any trouble here.

It will fall back on xpm icons.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the XEmacs operating system.

Re: svn icons in the toolbar

[Leo]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On 2007-08-30 06:08 +0100, Jan Djärv wrote:
> Leo skrev:
>> Hi there,
>>
>> Is it possible now to make the toolbar support svg or png icons? For png
>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>
> That would be great.  It has been suggested that Emacs should use
> the new Gnome icons (http://people.freedesktop.org/~jimmac/).  It
> would be so much easier if we just could copy the png images.
>
> 	Jan D.

It looks like the patch is not needed anymore. I compiled Emacs from CVS
HEAD without any patch, the toolbar was able to display icons from gtk2
theme though there is only diropen falling back on the old xpm. See the
screenshot:


[-- Attachment #2: emacs-mtty.png --]
[-- Type: image/png, Size: 26610 bytes --]

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]


I am not sure whether Emacs using other toolkit might need the patch or
not.

HTH,
-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: svn icons in the toolbar

[Benjamin Hawkes-Lewis]

Leo wrote:

> It looks like the patch is not needed anymore. I compiled Emacs from CVS
> HEAD without any patch, the toolbar was able to display icons from gtk2
> theme though there is only diropen falling back on the old xpm.

Hmm. I think something very weird is going on there (maybe you haven't 
clean out all traces of the patch from where Emacs looks to compile or 
run?). tool-bar.el from HEAD doesn't look for PNG files:

http://urlx.org/gnu.org/1bd12

--
Benjamin Hawkes-Lewis

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
>> Leo skrev:
>>> Hi there,
>>>
>>> Is it possible now to make the toolbar support svg or png icons? For png
>>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>> That would be great.  It has been suggested that Emacs should use
>> the new Gnome icons (http://people.freedesktop.org/~jimmac/).  It
>> would be so much easier if we just could copy the png images.
>>
>> 	Jan D.
> 
> It looks like the patch is not needed anymore. I compiled Emacs from CVS
> HEAD without any patch, the toolbar was able to display icons from gtk2
> theme though there is only diropen falling back on the old xpm. See the
> screenshot:
> 

It works for the Gtk+ port only.  We now use stock items and Gtk+ does all the
file loading and rendering.  But for other ports (Xt, X11, OSX, W32) only xpm
are used still.  So I think the patch should go in.

	Jan D.

Re: svn icons in the toolbar

[Jan Djärv]

Benjamin Hawkes-Lewis skrev:
> Leo wrote:
> 
>> It looks like the patch is not needed anymore. I compiled Emacs from CVS
>> HEAD without any patch, the toolbar was able to display icons from gtk2
>> theme though there is only diropen falling back on the old xpm.
> 
> Hmm. I think something very weird is going on there (maybe you haven't
> clean out all traces of the patch from where Emacs looks to compile or
> run?). tool-bar.el from HEAD doesn't look for PNG files:
> 
> http://urlx.org/gnu.org/1bd12
> 

No, but there is a mapping from files to gtk stock items in
lisp/term/x-win.el.  If you compile Emacs for Gtk+, stock items will be used,
and that means PNG files will be loaded by Gtk+ itself.

	Jan D.

Re: svn icons in the toolbar

[Leo]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On 2007-09-02 09:23 +0100, Jan Djärv wrote:
> Leo skrev:
>> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
>>> Leo skrev:
>>>> Hi there,
>
>>>>
>>>> Is it possible now to make the toolbar support svg or png icons? For png
>>>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>>> That would be great.  It has been suggested that Emacs should use
>>> the new Gnome icons (http://people.freedesktop.org/~jimmac/).  It
>>> would be so much easier if we just could copy the png images.
>>>
>>> 	Jan D.
>> 
>> It looks like the patch is not needed anymore. I compiled Emacs from CVS
>> HEAD without any patch, the toolbar was able to display icons from gtk2
>> theme though there is only diropen falling back on the old xpm. See the
>> screenshot:
>> 
>
> It works for the Gtk+ port only.  We now use stock items and Gtk+ does
> all the file loading and rendering.  But for other ports (Xt, X11,
> OSX, W32) only xpm are used still.  So I think the patch should go in.
>
> 	Jan D.

Thanks for explanation.

However have you noticed the 3rd icon on the tool-bar is still from the
old xpm images. A new one could look like this:


[-- Attachment #2: file-manager.png --]
[-- Type: image/png, Size: 1123 bytes --]

[-- Attachment #3: Type: text/plain, Size: 132 bytes --]


HTH,
-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-02 09:23 +0100, Jan Djärv wrote:
>> Leo skrev:
>>> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
>>>> Leo skrev:
>>>>> Hi there,
>>>>> Is it possible now to make the toolbar support svg or png icons? For png
>>>>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>>>> That would be great.  It has been suggested that Emacs should use
>>>> the new Gnome icons (http://people.freedesktop.org/~jimmac/).  It
>>>> would be so much easier if we just could copy the png images.
>>>>
>>>> 	Jan D.
>>> It looks like the patch is not needed anymore. I compiled Emacs from CVS
>>> HEAD without any patch, the toolbar was able to display icons from gtk2
>>> theme though there is only diropen falling back on the old xpm. See the
>>> screenshot:
>>>
>> It works for the Gtk+ port only.  We now use stock items and Gtk+ does
>> all the file loading and rendering.  But for other ports (Xt, X11,
>> OSX, W32) only xpm are used still.  So I think the patch should go in.
>>
>> 	Jan D.
> 
> Thanks for explanation.
> 
> However have you noticed the 3rd icon on the tool-bar is still from the
> old xpm images. A new one could look like this:
> 

Yes, I've noticed.  That is because I found no suitable stock icon for it.
Does the icon you attached have a stock name?  Where is it from?

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-09-02 14:29 +0100, Jan Djärv wrote:
> Leo skrev:
>> On 2007-09-02 09:23 +0100, Jan Djärv wrote:
>>> Leo skrev:
>>>> On 2007-08-30 06:08 +0100, Jan Djärv wrote:
>
>>>>> Leo skrev:
>>>>>> Hi there,
>>>>>> Is it possible now to make the toolbar support svg or png icons? For png
>>>>>> support There is a patch in article: <1169151517.24488.17.camel@galahad>
>>>>> That would be great.  It has been suggested that Emacs should use
>>>>> the new Gnome icons (http://people.freedesktop.org/~jimmac/).  It
>>>>> would be so much easier if we just could copy the png images.
>>>>>
>>>>> 	Jan D.
>>>> It looks like the patch is not needed anymore. I compiled Emacs from CVS
>>>> HEAD without any patch, the toolbar was able to display icons from gtk2
>>>> theme though there is only diropen falling back on the old xpm. See the
>>>> screenshot:
>>>>
>>> It works for the Gtk+ port only.  We now use stock items and Gtk+ does
>>> all the file loading and rendering.  But for other ports (Xt, X11,
>>> OSX, W32) only xpm are used still.  So I think the patch should go in.
>>>
>>> 	Jan D.
>> 
>> Thanks for explanation.
>> 
>> However have you noticed the 3rd icon on the tool-bar is still from the
>> old xpm images. A new one could look like this:
>> 
>
> Yes, I've noticed.  That is because I found no suitable stock icon for it.
> Does the icon you attached have a stock name?  Where is it from?
>
> 	Jan D.

It is in:

/usr/share/icons/gnome/32x32/apps/system-file-manager.png

dired is a file manager, right?

If you really want to use the gtk-stock icon, GTK_STOCK_DIRECTORY can be
a good candidate although I feel it is not as nice as
system-file-manager.png.

HTH,
-- 
Leo

Redundant icon in tool-bar (was: svn icons in the toolbar)

[Leo]

Dear all,

Today I suddenly found that the first icon and the second icon from the
left are substantially similar in functionality. The third icon is
likely to have a similar icon to the second one (some sort of directory
icon). Thus I think it might be better to remove the second icon from
the tool-bar. It make it look simpler yet doesn't reduce any
functionality.

On 2007-09-02 14:29 +0100, Jan Djärv wrote:
>> However have you noticed the 3rd icon on the tool-bar is still from the
>> old xpm images. A new one could look like this:
>> 
>
> Yes, I've noticed.  That is because I found no suitable stock icon for it.
> Does the icon you attached have a stock name?  Where is it from?

HTH,
-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Leo]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On 2007-09-02 14:29 +0100, Jan Djärv wrote:
>> However have you noticed the 3rd icon on the tool-bar is still from the
>> old xpm images. A new one could look like this:
>> 
>
> Yes, I've noticed.  That is because I found no suitable stock icon for it.
> Does the icon you attached have a stock name?  Where is it from?

Have you noticed that the tool-bar in Gnus's article buffer, summary
buffer and message buffer has gone back to using the old-fashioned icons
or missing a couple of icons. See:


[-- Attachment #2: Gnus-sum.png --]
[-- Type: image/png, Size: 20017 bytes --]

[-- Attachment #3: Gnus-msg.png --]
[-- Type: image/png, Size: 38358 bytes --]

[-- Attachment #4: Type: text/plain, Size: 132 bytes --]


HTH,
-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Redundant icon in tool-bar

[Jan Djärv]

Leo skrev:
> Dear all,
> 
> Today I suddenly found that the first icon and the second icon from the
> left are substantially similar in functionality. The third icon is
> likely to have a similar icon to the second one (some sort of directory
> icon). Thus I think it might be better to remove the second icon from
> the tool-bar. It make it look simpler yet doesn't reduce any
> functionality.

It does not reduce functionality per se, but the file open dialogs look and
behave different.

	Jan D.

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-02 14:29 +0100, Jan Djärv wrote:
>>> However have you noticed the 3rd icon on the tool-bar is still from the
>>> old xpm images. A new one could look like this:
>>>
>> Yes, I've noticed.  That is because I found no suitable stock icon for it.
>> Does the icon you attached have a stock name?  Where is it from?
> 
> Have you noticed that the tool-bar in Gnus's article buffer, summary
> buffer and message buffer has gone back to using the old-fashioned icons
> or missing a couple of icons. See:
> 

I don't use Gnus, so no.  However, there was a bug that made icons change, how
old is your Emacs?  Try update from head and try again.

There is no mapping from file names to stock itemns yet, so the old xpm icons
will be used.  It is the same for almost all parts of Emacs (gud, gnus, mail,
...), except info and the main tool bar.

	Jan D.

Re: Redundant icon in tool-bar

[Leo]

On 2007-09-02 16:39 +0100, Jan Djärv wrote:
>> Today I suddenly found that the first icon and the second icon from the
>> left are substantially similar in functionality. The third icon is
>> likely to have a similar icon to the second one (some sort of directory
>> icon). Thus I think it might be better to remove the second icon from
>> the tool-bar. It make it look simpler yet doesn't reduce any
>> functionality.
>
> It does not reduce functionality per se, but the file open dialogs look and
> behave different.

The second one won't allow to open a non-existent file.

For beginners, the difference is not important or many of them fail to
realize the difference. And once they get used to Emacs, they start
turning tool-bar off anyway.

That the two icons behave substantially similarly creates confusion for
users.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Leo]

On 2007-09-02 16:43 +0100, Jan Djärv wrote:
> I don't use Gnus, so no.  However, there was a bug that made icons change, how
> old is your Emacs?  Try update from head and try again.

GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14, multi-tty) of 2007-09-01

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-02 16:43 +0100, Jan Djärv wrote:
>> I don't use Gnus, so no.  However, there was a bug that made icons change, how
>> old is your Emacs?  Try update from head and try again.
> 
> GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14, multi-tty) of 2007-09-01
> 

I can't repeat it.  Are you sure you have a clean install with all icon files
present?  Can you give a case starting from emacs -Q where this occurs?

	Jan D.

Re: svn icons in the toolbar

[Jan Djärv]

Jan Djärv skrev:
> Leo skrev:

>>
>> However have you noticed the 3rd icon on the tool-bar is still from the
>> old xpm images. A new one could look like this:
>>
> 
> Yes, I've noticed.  That is because I found no suitable stock icon for it.
> Does the icon you attached have a stock name?  Where is it from?
> 

I think it is the named icon system-file-manager.  I added that one.

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-09-02 18:46 +0100, Jan Djärv wrote:
> Jan Djärv skrev:
>> Leo skrev:
>
>>>
>>> However have you noticed the 3rd icon on the tool-bar is still from the
>>> old xpm images. A new one could look like this:
>>>
>> 
>> Yes, I've noticed.  That is because I found no suitable stock icon for it.
>> Does the icon you attached have a stock name?  Where is it from?
>> 
>
> I think it is the named icon system-file-manager.  I added that one.
>
> 	Jan D.

The main tool-bar now looks beautiful. However the info tool-bar need
some love. I will come back to this later.

Thanks,
-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Richard Stallman]

    > I think that would cause more trouble than it is worth, because not
    > all systems have development versions of png libraries installed (as I
    > recently found).

    I don't think there is any trouble here.

    It will fall back on xpm icons.

If they are good enough, why not simply use them always?
Why use other formats at all?

Re: svn icons in the toolbar

[Jan Djärv]

Richard Stallman skrev:
>     > I think that would cause more trouble than it is worth, because not
>     > all systems have development versions of png libraries installed (as I
>     > recently found).
> 
>     I don't think there is any trouble here.
> 
>     It will fall back on xpm icons.
> 
> If they are good enough, why not simply use them always?
> Why use other formats at all?
> 

If you want to try out or replace Emacs icons with something else, it is 
easier to just copy png icons to etc/images, or set image-load-path to a 
directory with png icons (png seems to be the most used format for Gnome and 
KDE), than to first convert them to xpm.  Also, I think xpm had some issues 
with transparency, but that may have been solved now.

	Jan D.

Re: svn icons in the toolbar

[Benjamin Hawkes-Lewis]

Richard Stallman wrote:

>     I don't think there is any trouble here.
> 
>     It will fall back on xpm icons.
> 
> If they are good enough, why not simply use them always?
> Why use other formats at all?

Well, "fall back" tends to imply "not as good".

Aesthetically, the XPM icons may be serviceable for a fallback but they 
aren't "good enough" when the other programs on your desktop are using 
PNG or SVG icons. That's why I was motivated to write my patch in the 
first place. ;)

--
Benjamin Hawkes-Lewis

Re: svn icons in the toolbar

[joakim]

Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> writes:

> Richard Stallman wrote:
>
>>     I don't think there is any trouble here.
>>
>>     It will fall back on xpm icons.
>>
>> If they are good enough, why not simply use them always?
>> Why use other formats at all?
>
> Well, "fall back" tends to imply "not as good".
>
> Aesthetically, the XPM icons may be serviceable for a fallback but
> they aren't "good enough" when the other programs on your desktop are
> using PNG or SVG icons. That's why I was motivated to write my patch
> in the first place. ;)

Disclaimer: I always disable the toolbar.

That said, I also wonder why converting png:s to xpm wouldnt be
equivalent. Does the png library handle alpha channels and
anti-aliasing to the background conveniently, which the xpm library
presumably doesnt? Or what is the technical cause for xpm:s visual
inferiority?

I can understand that SVG:s are superior when scaling of course.

>
> --
> Benjamin Hawkes-Lewis

-- 
Joakim Verona

Re: svn icons in the toolbar

[Leo]

On 2007-09-03 04:04 +0100, Richard Stallman wrote:
>     > I think that would cause more trouble than it is worth, because not
>     > all systems have development versions of png libraries installed (as I
>     > recently found).
>
>     I don't think there is any trouble here.
>
>     It will fall back on xpm icons.
>
> If they are good enough, why not simply use them always?
> Why use other formats at all?

They are good enough for some people and some systems. But Emacs looks
much better with png icons, as it's superior to xpm.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Leo]

On 2007-09-03 08:53 +0100, joakim@verona.se wrote:
> Does the png library handle alpha channels and
> anti-aliasing to the background conveniently

You said it.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On 3 Sep 2007, at 08:53, joakim@verona.se wrote:

> That said, I also wonder why converting png:s to xpm wouldnt be
> equivalent. Does the png library handle alpha channels and
> anti-aliasing to the background conveniently, which the xpm library
> presumably doesnt?

Correct.

For Aquamacs, I convert PNGs into XPMs with a pre-defined background  
color (matte), which is used in lieu of alpha blending. This works  
fine until the user changes the background color of the toolbar. A  
screenshot of the toolbar with some icons enabled is attached.

I tried using PNGs for the toolbar, and I wrote a patch to support  
that (see below, don't know if it still applies cleanly).

However, there always was a problem with the specification of  
selected / disabled states of the icons, which somehow didn't work  
correctly for PNGs at least in the Carbon port (IIRC - this is more  
than a year ago).

It would be very nice if PNGs worked, and if selected and disabled  
states were fully supported.

Alternatively, the IMHO much better solution would be to support  
toolkit toolbars, because that'll give users all the functionality of  
the toolkit (native look, best quality images, in some cases  
drag&drop / reordering). A fallback to XPM is always possible, of  
course, in non-toolkit builds.



[-- Attachment #2: pastedGraphic.png --]
[-- Type: image/png, Size: 28016 bytes --]

[-- Attachment #3: pastedGraphic.png --]
[-- Type: image/png, Size: 96682 bytes --]

[-- Attachment #4: Type: text/plain, Size: 7640 bytes --]

Index: lisp/tool-bar.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/tool-bar.el,v
retrieving revision 1.5
diff -c -r1.5 tool-bar.el
*** lisp/tool-bar.el	6 Feb 2006 14:33:35 -0000	1.5
--- lisp/tool-bar.el	2 May 2006 11:18:01 -0000
***************
*** 90,95 ****
--- 90,166 ----
   		'(menu-item "tool bar" ignore
   			    :filter (lambda (ignore) tool-bar-map)))

+ (defun tool-bar-set-file-extension (image-spec-list extension)
+   "Set new file extensions for all :file properties
+ Replace any extensions of :file properties in elements of
+ IMAGE-SPEC-LIST. An extension may start with a period . or an
+ underscore. EXTENSION and the original file name extension (starting
+ with a period) are added to the file name.
+
+ E.g. foo_dis.xpm becomes foo_sel.xpm if EXTENSION is '_sel'."
+   (mapcar
+    (lambda (spec)
+      (let ((f (plist-get spec :file))
+ 	    )
+         (if (null f)
+ 	    spec
+ 	  ;; need to replace previous extensions, including those
+ 	  ;; starting with _ -
+ 	  (plist-put spec :file (concat (replace-regexp-in-string "[\.\_].*$"
+ 								  "" f)
+ 					extension
+ 					(file-name-extension f t)))
+ 	  )))
+    image-spec-list))
+
+ ;; (cdr (tool-bar-get-image-spec "new"))
+ (defun tool-bar-get-image-spec (icon)
+   (let* ((fg (face-attribute 'tool-bar :foreground))
+ 	 (bg (face-attribute 'tool-bar :background))
+ 	 (colors (nconc (if (eq fg 'unspecified) nil (list :foreground fg))
+ 			(if (eq bg 'unspecified) nil (list :background bg))))
+ 	 (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
+ 	 (xpm-lo-spec (if (> (display-color-cells) 256)
+ 			  nil
+ 			(list :type 'xpm :file
+                               (concat "low-color/" icon ".xpm"))))
+ 	 (png-spec (list :type 'png
+ 			   :file (concat icon ".png")) )
+ 	 (pbm-spec (append (list :type 'pbm :file
+                                  (concat icon ".pbm")) colors))
+ 	 (xbm-spec (append (list :type 'xbm :file
+                                  (concat icon ".xbm")) colors))
+ 	 (image (find-image
+ 		(if (display-color-p)
+ 		    (list png-spec xpm-lo-spec xpm-spec pbm-spec xbm-spec)
+ 		  (list pbm-spec xbm-spec xpm-lo-spec xpm-spec))))
+ 	 (image-sel (find-image
+ 		     (if (display-color-p)
+ 			 (tool-bar-set-file-extension
+ 			  (list png-spec xpm-lo-spec xpm-spec pbm-spec xbm-spec)
+ 			  "_sel")
+ 		       nil)))
+ 	 (image-dis (find-image
+ 		     (if (display-color-p)
+ 			 (tool-bar-set-file-extension
+ 			  (list png-spec xpm-lo-spec xpm-spec pbm-spec xbm-spec)
+ 			  "_dis")
+ 		       nil)))
+ 	 (images (when image ;; image may be nil if not found.
+ 		   (unless (image-mask-p image)
+ 		     (setq image (append image '(:mask heuristic))))
+ 		   (if (and image-sel image-dis)
+ 		       (progn		
+ 			 (unless (image-mask-p image-sel)
+ 			   (setq image-sel (append image-sel
+ 						   '(:mask heuristic))))
+ 			 (unless (image-mask-p image-dis)
+ 			   (setq image-dis (append image-dis
+ 						   '(:mask heuristic))))
+ 			 (vector image-sel image image-dis image-dis))
+ 		     image))))
+     (cons image images)))
+
   ;;;###autoload
   (defun tool-bar-add-item (icon def key &rest props)
     "Add an item to the tool bar.
***************
*** 119,147 ****
   function will first try to use low-color/ICON.xpm if display-color- 
cells
   is less or equal to 256, then ICON.xpm, then ICON.pbm, and finally
   ICON.xbm, using `find-image'."
!   (let* ((fg (face-attribute 'tool-bar :foreground))
! 	 (bg (face-attribute 'tool-bar :background))
! 	 (colors (nconc (if (eq fg 'unspecified) nil (list :foreground fg))
! 			(if (eq bg 'unspecified) nil (list :background bg))))
! 	 (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
! 	 (xpm-lo-spec (if (> (display-color-cells) 256)
! 			  nil
! 			(list :type 'xpm :file
!                               (concat "low-color/" icon ".xpm"))))
! 	 (pbm-spec (append (list :type 'pbm :file
!                                  (concat icon ".pbm")) colors))
! 	 (xbm-spec (append (list :type 'xbm :file
!                                  (concat icon ".xbm")) colors))
! 	 (image (find-image
! 		(if (display-color-p)
! 		    (list xpm-lo-spec xpm-spec pbm-spec xbm-spec)
! 		  (list pbm-spec xbm-spec xpm-lo-spec xpm-spec)))))

       (when (and (display-images-p) image)
!       (unless (image-mask-p image)
! 	(setq image (append image '(:mask heuristic))))
         (define-key-after map (vector key)
! 	`(menu-item ,(symbol-name key) ,def :image ,image ,@props)))))

   ;;;###autoload
   (defun tool-bar-add-item-from-menu (command icon &optional map  
&rest props)
--- 190,203 ----
   function will first try to use low-color/ICON.xpm if display-color- 
cells
   is less or equal to 256, then ICON.xpm, then ICON.pbm, and finally
   ICON.xbm, using `find-image'."
!   (let* ((is (tool-bar-get-image-spec icon))
! 	 (image (car is))
! 	 (images (cdr is)))

       (when (and (display-images-p) image)
!
         (define-key-after map (vector key)
! 	`(menu-item ,(symbol-name key) ,def :image ,images ,@props)))))

   ;;;###autoload
   (defun tool-bar-add-item-from-menu (command icon &optional map  
&rest props)
***************
*** 174,196 ****
       (setq from-map global-map))
     (let* ((menu-bar-map (lookup-key from-map [menu-bar]))
   	 (keys (where-is-internal command menu-bar-map))
! 	 (fg (face-attribute 'tool-bar :foreground))
! 	 (bg (face-attribute 'tool-bar :background))
! 	 (colors (nconc (if (eq fg 'unspecified) nil (list :foreground fg))
! 			(if (eq bg 'unspecified) nil (list :background bg))))
! 	 (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
! 	 (xpm-lo-spec (if (> (display-color-cells) 256)
! 			  nil
! 			(list :type 'xpm :file
!                               (concat "low-color/" icon ".xpm"))))
! 	 (pbm-spec (append (list :type 'pbm :file
!                                  (concat icon ".pbm")) colors))
! 	 (xbm-spec (append (list :type 'xbm :file
!                                  (concat icon ".xbm")) colors))
! 	 (spec (if (display-color-p)
! 		   (list xpm-lo-spec xpm-spec pbm-spec xbm-spec)
! 		 (list pbm-spec xbm-spec xpm-lo-spec xpm-spec)))
! 	 (image (find-image spec))
   	 submap key)
       (when (and (display-images-p) image)
         ;; We'll pick up the last valid entry in the list of keys if
--- 230,238 ----
       (setq from-map global-map))
     (let* ((menu-bar-map (lookup-key from-map [menu-bar]))
   	 (keys (where-is-internal command menu-bar-map))
! 	 (is (tool-bar-get-image-spec icon))
! 	 (image (car is))
! 	 (images (cdr is))
   	 submap key)
       (when (and (display-images-p) image)
         ;; We'll pick up the last valid entry in the list of keys if
***************
*** 210,221 ****
   			key kk)))))
         (when (and (symbolp submap) (boundp submap))
   	(setq submap (eval submap)))
-       (unless (image-mask-p image)
- 	(setq image (append image '(:mask heuristic))))
         (let ((defn (assq key (cdr submap))))
   	(if (eq (cadr defn) 'menu-item)
   	    (define-key-after in-map (vector key)
! 	      (append (cdr defn) (list :image image) props))
   	  (setq defn (cdr defn))
   	  (define-key-after in-map (vector key)
   	    (let ((rest (cdr defn)))
--- 252,261 ----
   			key kk)))))
         (when (and (symbolp submap) (boundp submap))
   	(setq submap (eval submap)))
         (let ((defn (assq key (cdr submap))))
   	(if (eq (cadr defn) 'menu-item)
   	    (define-key-after in-map (vector key)
! 	      (append (cdr defn) (list :image images) props))
   	  (setq defn (cdr defn))
   	  (define-key-after in-map (vector key)
   	    (let ((rest (cdr defn)))


[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: svn icons in the toolbar

[Richard Stallman]

    If you want to try out or replace Emacs icons with something else, it is 
    easier to just copy png icons to etc/images, or set image-load-path to a 
    directory with png icons (png seems to be the most used format for Gnome and 
    KDE), than to first convert them to xpm.

That is an argument in favor of supporting other image formats
for icons.  I agree, it is good to support that, when the other
image formats are supported in general.

But I thought someone was arguing for switching to a different format
for the standard Emacs icons.  That's what I don't see a reason for.

Re: svn icons in the toolbar

[Richard Stallman]

    Aesthetically, the XPM icons may be serviceable for a fallback but they 
    aren't "good enough" when the other programs on your desktop are using 
    PNG or SVG icons.

Why do you think XPM icons are not good enough?
What is better about the PNG or SVG icons?

Joakim wrote:

    I can understand that SVG:s are superior when scaling of course.

Does Emacs do scaling of toolbar icons?
If so, when, and why is it important?

Leo wrote:

    > Does the png library handle alpha channels and
    > anti-aliasing to the background conveniently

    You said it.

I don't understand this -- what are "alpha channels"?  Maybe I
understand "anti-aliasing to the background", but the background for
the toolbar is trivial, right?

Can someone explain what different this makes
_for the toolbar_, and when and why?

Re: svn icons in the toolbar

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Sep 03, 2007 at 08:56:51PM -0400, Richard Stallman wrote:
>     Aesthetically, the XPM icons may be serviceable for a fallback but they 
>     aren't "good enough" when the other programs on your desktop are using 
>     PNG or SVG icons.
> 
> Why do you think XPM icons are not good enough?
> What is better about the PNG or SVG icons?

PNG: mainly alpha channel. Basically a "fourth" colour carrying
transparency information (in PNG with the same resolution as the other
three colour channels, what means that the image can be more-or-less
transparent at each pixel).

SVG: scaling. You don't have to support one set of icons for each
resolution. That said, I haven't managed to like the SVG icons offered
by the usual desktop environments. I use PNGs whenever possible :-/

> Does Emacs do scaling of toolbar icons?
> If so, when, and why is it important?

Since screen resolutions and user preferences vary quite a bit, there is
a need to support different "sized" (meaning the pixel size) icon sets.
Or just provide scalable icons and let the rendering engine do that
dynamically.

[...]

> I don't understand this -- what are "alpha channels"?  Maybe I
> understand "anti-aliasing to the background", but the background for
> the toolbar is trivial, right?

Right. There must be code in place to do that (on every theme change).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFG3Ni1Bcgs9XrR2kYRAsbuAJ0b0OBnsebLEeZwJrsxeIXVmB4DIQCcCUwa
C8MdkSWgd5OTe8q1J4ys3+k=
=7TKb
-----END PGP SIGNATURE-----

Re: svn icons in the toolbar

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 03 Sep 2007 20:56:51 -0400, Richard Stallman <rms@gnu.org> said:

> I don't understand this -- what are "alpha channels"?  Maybe I
> understand "anti-aliasing to the background", but the background for
> the toolbar is trivial, right?

FWIW, the tool-bar background is not necessarily a solid color if XPM
icons are used on non-GTK+ X11 builds.

(set-face-attribute 'tool-bar nil :stipple "hlines3" :foreground "gray85")

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: svn icons in the toolbar

[David Kastrup]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Mon, 03 Sep 2007 20:56:51 -0400, Richard Stallman <rms@gnu.org> said:
>
>> I don't understand this -- what are "alpha channels"?  Maybe I
>> understand "anti-aliasing to the background", but the background for
>> the toolbar is trivial, right?
>
> FWIW, the tool-bar background is not necessarily a solid color if XPM
> icons are used on non-GTK+ X11 builds.
>
> (set-face-attribute 'tool-bar nil :stipple "hlines3" :foreground "gray85")

Even when the background _is_ a solid color, the icon artwork of GNOME
and friends is rendered with subpixel resolution: that means that for
border pixels, a non-integral amount of background shines through.  If
the exact background is not known at the time an icon is made into a
graphics file, being restricted to transparency values of 0% and 100%
means that one either gets jagged edges or colored fringes around them
when displaying them.

For example, a blue icon rendered on red background will have border
pixels somewhere in the region between red and blue, depending on how
much of the background of a pixel gets covered.  Display this
magentaish color on a green background, and you have a magenta tinge
between the blue and red areas.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: svn icons in the toolbar

[Richard Stallman]

    PNG: mainly alpha channel. Basically a "fourth" colour carrying
    transparency information (in PNG with the same resolution as the other
    three colour channels, what means that the image can be more-or-less
    transparent at each pixel).

Thanks.  I know what transparency means; I did not recognize "alpha
channel" as a term for it.  (I usually do not know the latest jargon
terms for everything.)

    > Does Emacs do scaling of toolbar icons?
    > If so, when, and why is it important?

    Since screen resolutions and user preferences vary quite a bit, there is
    a need to support different "sized" (meaning the pixel size) icon sets.

Does Emacs need to scale its toolbar icons?

Re: svn icons in the toolbar

[Richard Stallman]

    FWIW, the tool-bar background is not necessarily a solid color if XPM
    icons are used on non-GTK+ X11 builds.

    (set-face-attribute 'tool-bar nil :stipple "hlines3" :foreground "gray85")

Ok, I see the advantage of PNG icons.

Re: svn icons in the toolbar

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 04 Sep 2007 18:57:42 -0400, Richard Stallman <rms@gnu.org> said:

>     FWIW, the tool-bar background is not necessarily a solid color if XPM
>     icons are used on non-GTK+ X11 builds.

>     (set-face-attribute 'tool-bar nil :stipple "hlines3" :foreground "gray85")

> Ok, I see the advantage of PNG icons.

Ah, I didn't mean that.

Strictly speaking, PNG/SVG alpha support in Emacs is limited in the
sense that it works properly only if the background is a solid color
and the color is explicitly specified in the image spec.  The above
example shows the case where the conditions do not hold.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: svn icons in the toolbar

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Sep 04, 2007 at 06:57:38PM -0400, Richard Stallman wrote:
>     PNG: mainly alpha channel [...]
> 
> Thanks.  I know what transparency means; I did not recognize "alpha
> channel" as a term for it.  (I usually do not know the latest jargon
> terms for everything.)

That's funny. In my group, I'm usually the old-fashioned guy playing
this role :-)

>     > Does Emacs do scaling of toolbar icons?
>     > If so, when, and why is it important?
> 
>     Since screen resolutions and user preferences vary quite a bit, there is
>     a need to support different "sized" (meaning the pixel size) icon sets.
> 
> Does Emacs need to scale its toolbar icons?

Hm. I don't know. If you ask me personally, I'd say no, thank you very
much. OTOH I do understand the "desktop folks" trying to achieve an
uniform (and themeable) look across all applications. Under this
premise, Emacs would have to use whatever icon set is provided by the
desktop theme, which nowadays is becoming more and more a scalable one.

Sorry for not giving a clear-cut answer.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFG3iMLBcgs9XrR2kYRAt+GAJ0YpAimv7IE0OtFGjPSFnKyPZUwqwCfd9mO
QXtHSmkwo/HR+4GcTqP9lRI=
=O9fI
-----END PGP SIGNATURE-----

Re: svn icons in the toolbar

[Richard Stallman]

It makes sense for Emacs to support using icons from a theme when a
theme provides one.  I'm in favor of supporting the display of PNG and
SVG icons in the tool bar.

Is someone proposing that we replace the icons in Emacs?  If so, why?
When themes provide their own icons, the icons in Emacs are not used
anyway.

Re: svn icons in the toolbar

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> It makes sense for Emacs to support using icons from a theme when a
> theme provides one.  I'm in favor of supporting the display of PNG and
> SVG icons in the tool bar.
>
> Is someone proposing that we replace the icons in Emacs?  If so, why?
> When themes provide their own icons, the icons in Emacs are not used
> anyway.

Png and svn icons look better than the xpm icons we are currently
using.  When you use other applications (e.g. Gnome applications) side
by side with Emacs, Emacs looks significantly frumpier.

Re: svn icons in the toolbar

[Leo]

On 2007-09-05 21:02 +0100, Richard Stallman wrote:
> Is someone proposing that we replace the icons in Emacs?  If so, why?
> When themes provide their own icons, the icons in Emacs are not used
> anyway.

I think the reason is that only gtk toolkit knows how to use icons in a
gnome icon theme. Is this correct, Jan?

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Leo]

On 2007-09-02 18:28 +0100, Jan Djärv wrote:
>> GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14,
>> multi-tty) of 2007-09-01
>
> I can't repeat it.  Are you sure you have a clean install with all
> icon files present?  Can you give a case starting from emacs -Q where
> this occurs?

Sorry for the delay.

My Emacs was installed from a fresh CVS check out on the first build
which you can see from 23.0.50.1.

Toobar and menubar are initially disabled.
Emacs.menuBar: 0
Emacs.toolBar: 0

Turn on tool-bar-mode and switch to gnus buffers and you can see the
weird tool-bar shown up.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Jan Djärv]

Richard Stallman skrev:
> It makes sense for Emacs to support using icons from a theme when a
> theme provides one.  I'm in favor of supporting the display of PNG and
> SVG icons in the tool bar.
> 
> Is someone proposing that we replace the icons in Emacs?  If so, why?

Emacs have uses Gnome tool bar icons, and now Gnome has moved forward with new 
icons.

> When themes provide their own icons, the icons in Emacs are not used
> anyway.

That only applies to the Gtk+ build.

	Jan D.

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-05 21:02 +0100, Richard Stallman wrote:
>> Is someone proposing that we replace the icons in Emacs?  If so, why?
>> When themes provide their own icons, the icons in Emacs are not used
>> anyway.
> 
> I think the reason is that only gtk toolkit knows how to use icons in a
> gnome icon theme. Is this correct, Jan?

Yes.

	Jan D.

Re: svn icons in the toolbar

[Richard Stallman]

    > Is someone proposing that we replace the icons in Emacs?  If so, why?

    Emacs have uses Gnome tool bar icons, and now Gnome has moved forward with new 
    icons.

It is so frustrating to deal with replacing icons so often.  Let's put
this off until we are about to pretest Emacs 23.  By then, they will
probably have different icons.

Re: svn icons in the toolbar

[Leo]

On 2007-09-07 07:32 +0100, Richard Stallman wrote:
> It is so frustrating to deal with replacing icons so often.  Let's put
> this off until we are about to pretest Emacs 23.  By then, they will
> probably have different icons.

If we have png support for toolbar, we can write a simple script to
update icons.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Jan Djärv]

Richard Stallman skrev:
>     > Is someone proposing that we replace the icons in Emacs?  If so, why?
> 
>     Emacs have uses Gnome tool bar icons, and now Gnome has moved forward with new 
>     icons.
> 
> It is so frustrating to deal with replacing icons so often.  Let's put
> this off until we are about to pretest Emacs 23.

Okay.


>  By then, they will probably have different icons.

:-)


Maybe we should consider implementing using theme icons for other builds as 
well?  But W32, cygwin and OSX would not benefit from that, so maybe not.

	Jan D.

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-07 07:32 +0100, Richard Stallman wrote:
>> It is so frustrating to deal with replacing icons so often.  Let's put
>> this off until we are about to pretest Emacs 23.  By then, they will
>> probably have different icons.
> 
> If we have png support for toolbar, we can write a simple script to
> update icons.
> 

No exactly, we still ned B&W and low color versions.

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-09-07 09:12 +0100, Jan Djärv wrote:
> No exactly, we still ned B&W and low color versions.

Presumably, those do not need to converted from Gnome icons. Why don't
we just use the old B&W and low color. If people can put up with B&W or
low color, they probably wouldn't even care.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: svn icons in the toolbar

[Richard Stallman]

    Maybe we should consider implementing using theme icons for other builds as 
    well?

That would be a good feature, so please do implement it if you want
to.

      But W32, cygwin and OSX would not benefit from that,

GNU and GNU/Linux are the most important platforms.
If the feature is useful for them, that's enough reason to add it.

Re: svn icons in the toolbar

[Richard Stallman]

Updating icons is a lot of work.  Perhaps you are just thinking of the
mechanics of installing new icon files, but that's just a little of
it.  For instance, we have to deal with license issues.

Please wait until Emacs 23 is close to ready for pretest,
then bring this up.

Re: svn icons in the toolbar

[Stephen Berman]

On Sun, 02 Sep 2007 19:46:52 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Jan Djärv skrev:
>> Leo skrev:
>
>>>
>>> However have you noticed the 3rd icon on the tool-bar is still from the
>>> old xpm images. A new one could look like this:
>>>
>> 
>> Yes, I've noticed.  That is because I found no suitable stock icon for it.
>> Does the icon you attached have a stock name?  Where is it from?
>> 
>
> I think it is the named icon system-file-manager.  I added that one.

I'm running GNU Emacs 23.0.50.3 (i686-pc-linux-gnu, GTK+ Version
2.10.6) of 2007-09-17 on escher under KDE 3.5.7.  The defcustom
x-gtk-stock-map from x-win.el contains this: ("etc/images/diropen"
. "n:system-file-manager").  Nevertheless, the relevant tool bars all
have diropen.xpm from etc/images rather than system-file-manager.png.
My system has the following system-file-manager icons:

    /opt/gnome/share/icons/gnome/16x16/apps/system-file-manager.png
    /opt/gnome/share/icons/gnome/22x22/apps/system-file-manager.png
    /opt/gnome/share/icons/gnome/24x24/apps/system-file-manager.png
    /opt/gnome/share/icons/gnome/32x32/apps/system-file-manager.png
    /usr/share/icons/Tango/128x128/apps/system-file-manager.png
    /usr/share/icons/Tango/16x16/apps/system-file-manager.png
    /usr/share/icons/Tango/22x22/apps/system-file-manager.png
    /usr/share/icons/Tango/24x24/apps/system-file-manager.png
    /usr/share/icons/Tango/32x32/apps/system-file-manager.png
    /usr/share/icons/Tango/48x48/apps/system-file-manager.png
    /usr/share/icons/Tango/64x64/apps/system-file-manager.png
    /usr/share/icons/Tango/72x72/apps/system-file-manager.png
    /usr/share/icons/Tango/96x96/apps/system-file-manager.png

When I run Emacs under Gnome, system-file-manager.png is used.  Note
that the tool bars do display the available Gnome stock icons under
KDE, it's just the named icon that isn't used.

Steve Berman

Re: svn icons in the toolbar

[Jan Djärv]

Stephen Berman skrev:
> On Sun, 02 Sep 2007 19:46:52 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Jan Djärv skrev:
>>> Leo skrev:
>>>> However have you noticed the 3rd icon on the tool-bar is still from the
>>>> old xpm images. A new one could look like this:
>>>>
>>> Yes, I've noticed.  That is because I found no suitable stock icon for it.
>>> Does the icon you attached have a stock name?  Where is it from?
>>>
>> I think it is the named icon system-file-manager.  I added that one.
> 
> I'm running GNU Emacs 23.0.50.3 (i686-pc-linux-gnu, GTK+ Version
> 2.10.6) of 2007-09-17 on escher under KDE 3.5.7.  The defcustom
> x-gtk-stock-map from x-win.el contains this: ("etc/images/diropen"
> . "n:system-file-manager").  Nevertheless, the relevant tool bars all
> have diropen.xpm from etc/images rather than system-file-manager.png.
> My system has the following system-file-manager icons:
> 
>     /opt/gnome/share/icons/gnome/16x16/apps/system-file-manager.png
>     /opt/gnome/share/icons/gnome/22x22/apps/system-file-manager.png
>     /opt/gnome/share/icons/gnome/24x24/apps/system-file-manager.png
>     /opt/gnome/share/icons/gnome/32x32/apps/system-file-manager.png
>     /usr/share/icons/Tango/128x128/apps/system-file-manager.png
>     /usr/share/icons/Tango/16x16/apps/system-file-manager.png
>     /usr/share/icons/Tango/22x22/apps/system-file-manager.png
>     /usr/share/icons/Tango/24x24/apps/system-file-manager.png
>     /usr/share/icons/Tango/32x32/apps/system-file-manager.png
>     /usr/share/icons/Tango/48x48/apps/system-file-manager.png
>     /usr/share/icons/Tango/64x64/apps/system-file-manager.png
>     /usr/share/icons/Tango/72x72/apps/system-file-manager.png
>     /usr/share/icons/Tango/96x96/apps/system-file-manager.png
> 
> When I run Emacs under Gnome, system-file-manager.png is used.  Note
> that the tool bars do display the available Gnome stock icons under
> KDE, it's just the named icon that isn't used.
> 

I don't think named icons work under anything else than Gnome.  The theme is 
set in XSETTINGS and that is maintained by the gnome settings daemon.  The 
Gtk+ stock icons however, are hardcoded in Gtk+.

	Jan D.

Re: svn icons in the toolbar

[Stephen Berman]

On Wed, 19 Sep 2007 08:26:24 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
[...]
>> When I run Emacs under Gnome, system-file-manager.png is used.  Note
>> that the tool bars do display the available Gnome stock icons under
>> KDE, it's just the named icon that isn't used.
>>
>
> I don't think named icons work under anything else than Gnome.  The
> theme is set in XSETTINGS and that is maintained by the gnome settings
> daemon.  The Gtk+ stock icons however, are hardcoded in Gtk+.

Can you imagine a workaround, some way to get the named icons on to
the tool bar under KDE?  It would be a pity to have to do without them
while using the Gnome stock icons.

Steve Berman

Re: svn icons in the toolbar

[Stephen Berman]

On Wed, 19 Sep 2007 08:26:24 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
[...]
>> When I run Emacs under Gnome, system-file-manager.png is used.  Note
>> that the tool bars do display the available Gnome stock icons under
>> KDE, it's just the named icon that isn't used.
>>
>
> I don't think named icons work under anything else than Gnome.  The
> theme is set in XSETTINGS and that is maintained by the gnome settings
> daemon.  The Gtk+ stock icons however, are hardcoded in Gtk+.
>
> 	Jan D.

Hmm, pity.  I wonder if there is a workaround, some way to get the
named icons on to the tool bar under KDE that circumvents the Gnome
settings daemon.  It would be a shame to have to do without those
icons while using the Gnome stock icons.

Steve Berman

Re: svn icons in the toolbar

[Leo]

On 2007-09-19 10:20 +0100, Stephen Berman wrote:
> Hmm, pity.  I wonder if there is a workaround, some way to get the
> named icons on to the tool bar under KDE that circumvents the Gnome
> settings daemon.  It would be a shame to have to do without those
> icons while using the Gnome stock icons.

I can see Emacs using the new icons in any window managers such as fvwm,
xmonad; however I don't have kde installed.

You probably need to set something in ~/.gtk-2.0.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: svn icons in the toolbar

[Jan Djärv]

Stephen Berman skrev:
> On Wed, 19 Sep 2007 08:26:24 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Stephen Berman skrev:
> [...]
>>> When I run Emacs under Gnome, system-file-manager.png is used.  Note
>>> that the tool bars do display the available Gnome stock icons under
>>> KDE, it's just the named icon that isn't used.
>>>
>> I don't think named icons work under anything else than Gnome.  The
>> theme is set in XSETTINGS and that is maintained by the gnome settings
>> daemon.  The Gtk+ stock icons however, are hardcoded in Gtk+.
>>
>> 	Jan D.
> 
> Hmm, pity.  I wonder if there is a workaround, some way to get the
> named icons on to the tool bar under KDE that circumvents the Gnome
> settings daemon.  It would be a shame to have to do without those
> icons while using the Gnome stock icons.

I'll try.  I currently don't have KDE installed, so it will take a while.

	Jan D.

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-19 10:20 +0100, Stephen Berman wrote:
>> Hmm, pity.  I wonder if there is a workaround, some way to get the
>> named icons on to the tool bar under KDE that circumvents the Gnome
>> settings daemon.  It would be a shame to have to do without those
>> icons while using the Gnome stock icons.
> 
> I can see Emacs using the new icons in any window managers such as fvwm,
> xmonad; however I don't have kde installed.
> 
> You probably need to set something in ~/.gtk-2.0.
> 

You can try

gtk-icon-theme-name = Tango

in ~/.emacs.d/gtkrc

However, the use of resource files is not guaranteed to work when stuff like 
gconfd is running.

	Jan D.

Re: svn icons in the toolbar

[Stephen Berman]

On Wed, 19 Sep 2007 10:54:04 +0100 Leo <sdl.web@gmail.com> wrote:

> On 2007-09-19 10:20 +0100, Stephen Berman wrote:
>> Hmm, pity.  I wonder if there is a workaround, some way to get the
>> named icons on to the tool bar under KDE that circumvents the Gnome
>> settings daemon.  It would be a shame to have to do without those
>> icons while using the Gnome stock icons.
>
> I can see Emacs using the new icons in any window managers such as fvwm,
> xmonad; however I don't have kde installed.
>
> You probably need to set something in ~/.gtk-2.0.

Hmm, all I have is ~/.gtkrc-1.2-gnome2:

	# Autowritten by gnome-settings-daemon. Do not edit
	
	include "/opt/gnome/share/themes/Raleigh/gtk/gtkrc"
	
	include "/home/steve/.gtkrc.mine"

and ~/.gtkrc-2.0:

	# This file was written by the Gtk-Qt-Engine
	# You can edit it in the KDE control center, under "GTK Styles and Fonts"
	
	include "/opt/gnome/share/themes/QtCurve/gtk-2.0/gtkrc"
	
	style "user-font"
	{
		font_name="Sans Serif 10"
	}
	widget_class "*" style "user-font"
	
	gtk-theme-name="QtCurve"
	gtk-font-name="Sans Serif 10"

The file /opt/gnome/share/themes/QtCurve/gtk-2.0/gtkrc contains
specifications for the appearance of the tool bar, among others, but
nothing about the icons used.

Steve Berman

Re: svn icons in the toolbar

[Stephen Berman]

On Wed, 19 Sep 2007 12:02:44 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
>> Hmm, pity.  I wonder if there is a workaround, some way to get the
>> named icons on to the tool bar under KDE that circumvents the Gnome
>> settings daemon.  It would be a shame to have to do without those
>> icons while using the Gnome stock icons.
>
> I'll try.  I currently don't have KDE installed, so it will take a while.

Thanks.  If there's any way I can help, please let me know.

Steve Berman

Re: svn icons in the toolbar

[Stephen Berman]

On Wed, 19 Sep 2007 08:26:24 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
>> On Sun, 02 Sep 2007 19:46:52 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>>> Jan Djärv skrev:
>>>> Leo skrev:
>>>>> However have you noticed the 3rd icon on the tool-bar is still from the
>>>>> old xpm images. A new one could look like this:
>>>>>
>>>> Yes, I've noticed.  That is because I found no suitable stock icon for it.
>>>> Does the icon you attached have a stock name?  Where is it from?
>>>>
>>> I think it is the named icon system-file-manager.  I added that one.
>>
>> I'm running GNU Emacs 23.0.50.3 (i686-pc-linux-gnu, GTK+ Version
>> 2.10.6) of 2007-09-17 on escher under KDE 3.5.7.  The defcustom
>> x-gtk-stock-map from x-win.el contains this: ("etc/images/diropen"
>> . "n:system-file-manager").  Nevertheless, the relevant tool bars all
>> have diropen.xpm from etc/images rather than system-file-manager.png.
>> My system has the following system-file-manager icons:
>>
>>     /opt/gnome/share/icons/gnome/16x16/apps/system-file-manager.png
>>     /opt/gnome/share/icons/gnome/22x22/apps/system-file-manager.png
>>     /opt/gnome/share/icons/gnome/24x24/apps/system-file-manager.png
>>     /opt/gnome/share/icons/gnome/32x32/apps/system-file-manager.png
>>     /usr/share/icons/Tango/128x128/apps/system-file-manager.png
>>     /usr/share/icons/Tango/16x16/apps/system-file-manager.png
>>     /usr/share/icons/Tango/22x22/apps/system-file-manager.png
>>     /usr/share/icons/Tango/24x24/apps/system-file-manager.png
>>     /usr/share/icons/Tango/32x32/apps/system-file-manager.png
>>     /usr/share/icons/Tango/48x48/apps/system-file-manager.png
>>     /usr/share/icons/Tango/64x64/apps/system-file-manager.png
>>     /usr/share/icons/Tango/72x72/apps/system-file-manager.png
>>     /usr/share/icons/Tango/96x96/apps/system-file-manager.png
>>
>> When I run Emacs under Gnome, system-file-manager.png is used.  Note
>> that the tool bars do display the available Gnome stock icons under
>> KDE, it's just the named icon that isn't used.
>>
>
> I don't think named icons work under anything else than Gnome.  The
> theme is set in XSETTINGS and that is maintained by the gnome settings
> daemon.  The Gtk+ stock icons however, are hardcoded in Gtk+.

I forgot that I am using the gtk-qt engine, which "allows GTK
applications to use Qt widget styles", including tool bar icons.  The
icons I see are actually KDE icons from
/opt/kde3/share/icons/crystalsvg/32x32/actions.  I assume gtk-qt maps
the Gnome stock icons to corresponding KDE icons of the selected
theme.  I couldn't find an icon in the crystal theme corresponding to
system-file-manager, but it may just be that gtk-qt does not handle
named Gnome icons.

Steve Berman

Re: svn icons in the toolbar

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]



Stephen Berman skrev:

> I forgot that I am using the gtk-qt engine, which "allows GTK
> applications to use Qt widget styles", including tool bar icons.  The
> icons I see are actually KDE icons from
> /opt/kde3/share/icons/crystalsvg/32x32/actions.  I assume gtk-qt maps
> the Gnome stock icons to corresponding KDE icons of the selected
> theme.  I couldn't find an icon in the crystal theme corresponding to
> system-file-manager, but it may just be that gtk-qt does not handle
> named Gnome icons.
> 

Try the attached program.  Compile like this:

% gcc -o icon-view icon-view.c `pkg-config  gtk+-2.0 --cflags --libs`

If run without arguments, it lists the named icons Gtk+ knows about.  The list 
may be long, I have 2309 names.

If you give it names as arguments, it displays a tool bar with those icons.

If it just list stock-* names, then the gtk-qt engine only deals with stock icons.

	Jan D.

[-- Attachment #2: icon-view.c --]
[-- Type: text/x-csrc, Size: 2147 bytes --]

#include <stdio.h>

#include <libintl.h>
#include <string.h>
#include <gtk/gtk.h>

static gboolean
destroy(GtkWidget *widget,
        GdkEvent *event,
        gpointer data)
{
    gtk_main_quit();
    return TRUE;
}

static gint
comp_func(gconstpointer a,
          gconstpointer b,
          gpointer user_data)
{
    return strcmp((const char *)a, (const char *)b);
}

int
main(int argc, char *argv[])
{
    gtk_set_locale();
    gtk_init(&argc, &argv);

    GtkWidget *wmain = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(wmain), "icon-view");

    g_signal_connect(G_OBJECT(wmain), "delete-event",
                     G_CALLBACK(destroy), 0);

    GtkWidget *tb = gtk_toolbar_new();
    GtkTooltips *wtooltip = gtk_tooltips_new();
    gtk_toolbar_set_show_arrow(GTK_TOOLBAR(tb), FALSE);
    gtk_toolbar_set_style(GTK_TOOLBAR(tb), GTK_TOOLBAR_ICONS);

    size_t i;

    if (argc == 1) {
        GdkDisplay *gdpy = gdk_display_get_default();
        GdkScreen *gscreen = gdk_display_get_default_screen(gdpy);
        GtkIconTheme *icontheme = gtk_icon_theme_get_for_screen(gscreen);
        GList *list = gtk_icon_theme_list_icons(icontheme, NULL);

        list = g_list_sort_with_data(list, comp_func, NULL);
        GList *it;
        for (it = list; it != NULL; it = g_list_next(it)) {
            printf("%s\n", (char *)it->data);
        }
        return 0;
    }

    for (i = 1; i < argc; ++i) {
        int is_stock = 0;
        const char *name = argv[i];
        if (strncmp("s:", name, 2) == 0) {
            is_stock = 1;
            name += 2;
        }

        GtkToolItem*  ti;
        if (is_stock) {
            ti = gtk_tool_button_new_from_stock(name);
        } else {
            ti = gtk_tool_button_new(NULL, NULL);
            gtk_tool_button_set_icon_name(GTK_TOOL_BUTTON(ti), name);
        }
        gtk_tool_item_set_expand(ti, TRUE);
        gtk_tool_item_set_tooltip(ti, wtooltip, name, NULL);
        gtk_toolbar_insert(GTK_TOOLBAR(tb), GTK_TOOL_ITEM(ti), -1);
    }

    gtk_container_add(GTK_CONTAINER(wmain), tb);
    gtk_widget_show_all(wmain);
    gtk_main();

    return 0;
}

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: svn icons in the toolbar

[Richard Stallman]

    Hmm, pity.  I wonder if there is a workaround, some way to get the
    named icons on to the tool bar under KDE that circumvents the Gnome
    settings daemon.

Do you mean, despite the absence of the GNOME settings daemon?
I agree.

Does KDE have any concept of standard icons?

Re: svn icons in the toolbar

[Leo]

On 2007-09-02 18:58 +0100, Leo wrote:
>> I think it is the named icon system-file-manager.  I added that one.
>>
>> 	Jan D.
>
> The main tool-bar now looks beautiful. However the info tool-bar need
> some love. I will come back to this later.

I cannot see any icons in the toolbar in info mode. It is just a blank
widget.

How can I find out what's wrong?

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-02 18:58 +0100, Leo wrote:
>>> I think it is the named icon system-file-manager.  I added that one.
>>>
>>> 	Jan D.
>> The main tool-bar now looks beautiful. However the info tool-bar need
>> some love. I will come back to this later.
> 
> I cannot see any icons in the toolbar in info mode. It is just a blank
> widget.
> 
> How can I find out what's wrong?
> 

Give a detailed description on how you eded up that way.  Does it happen when 
you do
% emacs -Q
C-h i

?

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-09-21 12:13 +0100, Jan Djärv wrote:
>> I cannot see any icons in the toolbar in info mode. It is just a blank
>> widget.
>>
>> How can I find out what's wrong?
>>
>
> Give a detailed description on how you eded up that way.  Does it
> happen when you do
> % emacs -Q
> C-h i
>
> ?
>
> 	Jan D.

I can only see it in my running Emacs. Can't reproduce it.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-21 12:13 +0100, Jan Djärv wrote:
>>> I cannot see any icons in the toolbar in info mode. It is just a blank
>>> widget.
>>>
>>> How can I find out what's wrong?
>>>
>> Give a detailed description on how you eded up that way.  Does it
>> happen when you do
>> % emacs -Q
>> C-h i
>>
>> ?
>>
>> 	Jan D.
> 
> I can only see it in my running Emacs. Can't reproduce it.
> 

Well, I don't know then.  Did you upgrade any files, libraries or so while 
Emacs was running?  If you kill the Emacs buffer (C-x k, not q) and open it 
again, is it still blank?

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-09-21 13:08 +0100, Jan Djärv wrote:
> Leo skrev:
>> On 2007-09-21 12:13 +0100, Jan Djärv wrote:
>>>> I cannot see any icons in the toolbar in info mode. It is just a blank
>>>> widget.
>>>>
>>>> How can I find out what's wrong?
>>>>
>>> Give a detailed description on how you eded up that way.  Does it
>>> happen when you do
>>> % emacs -Q
>>> C-h i
>>>
>>> ?
>>>
>>> 	Jan D.
>>
>> I can only see it in my running Emacs. Can't reproduce it.
>>
>
> Well, I don't know then.  Did you upgrade any files, libraries or so
> while Emacs was running? 

Never.

> If you kill the Emacs buffer (C-x k, not q) and open it again, is it
> still blank?
>
> 	Jan D.

After doing C-x k the main tool bar is also blank.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-21 13:08 +0100, Jan Djärv wrote:
>> Leo skrev:
>>> On 2007-09-21 12:13 +0100, Jan Djärv wrote:
>>>>> I cannot see any icons in the toolbar in info mode. It is just a blank
>>>>> widget.
>>>>>
>>>>> How can I find out what's wrong?
>>>>>
>>>> Give a detailed description on how you eded up that way.  Does it
>>>> happen when you do
>>>> % emacs -Q
>>>> C-h i
>>>>
>>>> ?
>>>>
>>>> 	Jan D.
>>> I can only see it in my running Emacs. Can't reproduce it.
>>>
>> Well, I don't know then.  Did you upgrade any files, libraries or so
>> while Emacs was running? 
> 
> Never.
> 
>> If you kill the Emacs buffer (C-x k, not q) and open it again, is it
>> still blank?
>>
>> 	Jan D.
> 
> After doing C-x k the main tool bar is also blank.
> 

It is Gtk+ that opens the files and paints the icons.  It should paint a 
broken image if it does not find them.  Can you try:

% strace -odebug -eopen -p <pid_of_emacs>

and then open a new frame in Emacs?
Then kill strace with control-C.  The file debug should contain open of the 
icon files, if they don't something is very broken.

	Jan D.

Re: svn icons in the toolbar

[Leo]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On 2007-09-21 14:08 +0100, Jan Djärv wrote:
>>> If you kill the Emacs buffer (C-x k, not q) and open it again, is it
>>> still blank?
>>>
>>> 	Jan D.
>>
>> After doing C-x k the main tool bar is also blank.
>>
>
> It is Gtk+ that opens the files and paints the icons.  It should
> paint a broken image if it does not find them.  Can you try:
>
> % strace -odebug -eopen -p <pid_of_emacs>
>
> and then open a new frame in Emacs?
> Then kill strace with control-C.  The file debug should contain open
> of the icon files, if they don't something is very broken.
>
> 	Jan D.

It might be mtty. After I start another emaclient I could not see that
the main toolbar is blank. Only the one in info mode is blank.


[-- Attachment #2: debug --]
[-- Type: application/octet-stream, Size: 34123 bytes --]

open("/proc/loadavg", O_RDONLY)         = 9
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/Documents/RC/freshers/HandBook/handbook2.tex", O_RDONLY|O_LARGEFILE) = 9
open("/dev/shm/KOMAArtikel.tex", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/.emacs.d/gnus", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/.emacs.d/etc/diary", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/Wiki/org/CU.org", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/Wiki/org/Tasks.org", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/Wiki/org/LaTeX.org", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/CU/2007-2008/office/culetter.tex", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/.emacs.d/etc/personal.diary", O_RDONLY|O_LARGEFILE) = 9
open("/home/leo/Wiki/org/PhD.org", O_RDONLY|O_LARGEFILE) = 9
open("/tmp/.gdmT2TNYT", O_RDONLY)       = 21
open("/tmp/.gdmT2TNYT", O_RDONLY)       = 21
open("/home/leo/.Xdefaults-sl392", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/left_ptr", O_RDONLY) = 21
open("/home/leo/.icons/default/cursors/sb_v_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/sb_v_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/sb_v_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/sb_v_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/sb_v_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/sb_v_double_arrow", O_RDONLY) = 21
open("/home/leo/.Xdefaults-localhost.localdomain", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 21
open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 21
open("/home/leo/.XCompose", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 21
open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 21
open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 21
open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 21
open("/home/leo/.XCompose", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 21
open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/xterm", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/left_ptr", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/watch", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/xterm", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/hand2", O_RDONLY) = 21
open("/home/leo/.icons/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/sb_h_double_arrow", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
open("/etc/gtk-2.0/gtkrc", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/themes/Clearlooks/gtk-2.0/gtkrc", O_RDONLY|O_LARGEFILE) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/xterm", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/left_ptr", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/left_ptr", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/watch", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/watch", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/xterm", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/xterm", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
open("/home/leo/.icons/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/hand2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/hand2", O_RDONLY) = 21
open("/home/leo/.icons/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/index.theme", O_RDONLY) = 21
open("/usr/share/pixmaps/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/default/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/cursors/sb_h_double_arrow", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/leo/.icons/Bluecurve/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/icons/Bluecurve/cursors/sb_h_double_arrow", O_RDONLY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
open("/usr/share/icons/Fedora/index.theme", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/Fedora/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/Fedora/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 22
open("/usr/share/icons/Mist/index.theme", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/Mist/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/Mist/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 22
open("/usr/share/icons/gnome/index.theme", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/gnome/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/gnome/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 22
open("/usr/share/icons/hicolor/index.theme", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 21
open("/usr/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = 22
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/16x16/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/16x16/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/22x22/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/22x22/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/24x24/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/24x24/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/32x32/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/32x32/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/36x36/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/36x36/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/48x48/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/48x48/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/64x64/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/64x64/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/96x96/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/96x96/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/128x128/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/128x128/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/192x192/apps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/hicolor/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons/hicolor/192x192/mimetypes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/home/leo/.local/share/icons/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/leo/.local/share/icons", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/usr/share/icons/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/icons", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/usr/local/share/pixmaps/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/share/pixmaps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
open("/usr/share/pixmaps/icon-theme.cache", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/pixmaps", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGALRM (Alarm clock) @ 0 (0) ---
open("/home/leo/Documents/RC/freshers/HandBook/handbook2.tex", O_RDONLY|O_LARGEFILE) = 21
open("/dev/shm/KOMAArtikel.tex", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/.emacs.d/gnus", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/.emacs.d/etc/diary", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/Wiki/org/CU.org", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/Wiki/org/Tasks.org", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/Wiki/org/LaTeX.org", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/CU/2007-2008/office/culetter.tex", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/.emacs.d/etc/personal.diary", O_RDONLY|O_LARGEFILE) = 21
open("/home/leo/Wiki/org/PhD.org", O_RDONLY|O_LARGEFILE) = 21
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]


HTH,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: svn icons in the toolbar

[Jan Djärv]

Leo skrev:
> On 2007-09-21 14:08 +0100, Jan Djärv wrote:
>>>> If you kill the Emacs buffer (C-x k, not q) and open it again, is it
>>>> still blank?
>>>>
>>>> 	Jan D.
>>> After doing C-x k the main tool bar is also blank.
>>>
>> It is Gtk+ that opens the files and paints the icons.  It should
>> paint a broken image if it does not find them.  Can you try:
>>
>> % strace -odebug -eopen -p <pid_of_emacs>
>>
>> and then open a new frame in Emacs?
>> Then kill strace with control-C.  The file debug should contain open
>> of the icon files, if they don't something is very broken.
>>
>> 	Jan D.
> 
> It might be mtty. After I start another emaclient I could not see that
> the main toolbar is blank. Only the one in info mode is blank.
> 

I see in your debug file that you have an icon cache.  It may be that one that 
is broken/updated.  Try

% gtk-update-icon-cache -f /usr/share/icons/Fedora
% gtk-update-icon-cache -f /usr/share/icons/Mist
% gtk-update-icon-cache -f /usr/share/icons/gnome
% gtk-update-icon-cache -f /usr/share/icons/hicolor

and then create a new frame.

I suspect some kind of Gtk+-bug.  So maybe just restart Emacs and continue...

	Jan D.

Re: svn icons in the toolbar

[Leo]

On 2007-09-21 16:14 +0100, Jan Djärv wrote:
>> It might be mtty. After I start another emaclient I could not see that
>> the main toolbar is blank. Only the one in info mode is blank.
>>
>
> I see in your debug file that you have an icon cache.  It may be
> that one that is broken/updated.  Try
>
> % gtk-update-icon-cache -f /usr/share/icons/Fedora
> % gtk-update-icon-cache -f /usr/share/icons/Mist
> % gtk-update-icon-cache -f /usr/share/icons/gnome
> % gtk-update-icon-cache -f /usr/share/icons/hicolor
>
> and then create a new frame.

no difference.

> I suspect some kind of Gtk+-bug.  So maybe just restart Emacs and
> continue...

Thanks ;)

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: svn icons in the toolbar

[Stephen Berman]

On Thu, 20 Sep 2007 08:24:46 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
>
>> I forgot that I am using the gtk-qt engine, which "allows GTK
>> applications to use Qt widget styles", including tool bar icons.  The
>> icons I see are actually KDE icons from
>> /opt/kde3/share/icons/crystalsvg/32x32/actions.  I assume gtk-qt maps
>> the Gnome stock icons to corresponding KDE icons of the selected
>> theme.  I couldn't find an icon in the crystal theme corresponding to
>> system-file-manager, but it may just be that gtk-qt does not handle
>> named Gnome icons.
>>
>
> Try the attached program.  Compile like this:
>
> % gcc -o icon-view icon-view.c `pkg-config  gtk+-2.0 --cflags --libs`
>
> If run without arguments, it lists the named icons Gtk+ knows about.
> The list may be long, I have 2309 names.
>
> If you give it names as arguments, it displays a tool bar with those icons.
>
> If it just list stock-* names, then the gtk-qt engine only deals
> with stock icons.

Thanks.  The program prints a list of 1279 names.  The list contains
only two items matching stock*: stock_keyring and stock_printers, and
only one item matching gtk*: gtkvim.  The list does not contain
system-file-manager.  I do not see how your program interacts with
gtk-qt.  I looked at the gtk-qt sources and found a function
doIconMapping() which IIUC maps a GTK+ stock icon to a corresponding
KDE icon, the specific icons are hardcoded in the function
setRcProperties().  I could not find any function that looked like it
handles names icons, but I could well have overlooked it.

Steve Berman

Re: svn icons in the toolbar

[Stephen Berman]

On Thu, 20 Sep 2007 12:35:17 -0400 Richard Stallman <rms@gnu.org> wrote:

>     Hmm, pity.  I wonder if there is a workaround, some way to get the
>     named icons on to the tool bar under KDE that circumvents the Gnome
>     settings daemon.
>
> Do you mean, despite the absence of the GNOME settings daemon?
> I agree.

In my case it is the gtk-qt engine that regulates the choice of
theme-related icons via a mapping from the GTK+ icons.  I don't know
the details of gtk-qt but I assume it doesn't use the GNOME settings
daemon. 

> Does KDE have any concept of standard icons?

I am not familiar with the KDE icon API but I briefly searched the
docs on my system as well as the web and couldn't find anything for
KDE icons that seems similar to GNOME's stock icons.

Steve Berman

Re: svn icons in the toolbar

[Jan Djärv]

Stephen Berman skrev:
> On Thu, 20 Sep 2007 08:24:46 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Stephen Berman skrev:
>>
>>> I forgot that I am using the gtk-qt engine, which "allows GTK
>>> applications to use Qt widget styles", including tool bar icons.  The
>>> icons I see are actually KDE icons from
>>> /opt/kde3/share/icons/crystalsvg/32x32/actions.  I assume gtk-qt maps
>>> the Gnome stock icons to corresponding KDE icons of the selected
>>> theme.  I couldn't find an icon in the crystal theme corresponding to
>>> system-file-manager, but it may just be that gtk-qt does not handle
>>> named Gnome icons.
>>>
>> Try the attached program.  Compile like this:
>>
>> % gcc -o icon-view icon-view.c `pkg-config  gtk+-2.0 --cflags --libs`
>>
>> If run without arguments, it lists the named icons Gtk+ knows about.
>> The list may be long, I have 2309 names.
>>
>> If you give it names as arguments, it displays a tool bar with those icons.
>>
>> If it just list stock-* names, then the gtk-qt engine only deals
>> with stock icons.
> 
> Thanks.  The program prints a list of 1279 names.  The list contains
> only two items matching stock*: stock_keyring and stock_printers, and
> only one item matching gtk*: gtkvim.  The list does not contain
> system-file-manager.  I do not see how your program interacts with
> gtk-qt.

It does not, it just uses Gtk+ functions. gtk-qt does its job behind the scenes.

> I looked at the gtk-qt sources and found a function
> doIconMapping() which IIUC maps a GTK+ stock icon to a corresponding
> KDE icon, the specific icons are hardcoded in the function
> setRcProperties().  I could not find any function that looked like it
> handles names icons, but I could well have overlooked it.
> 

There are relativly few stock icons, so mapping those to Qt-icons is not that
hard.  But over 2000 named icons is probably too much for Qt to attempt.

	Jan D.

Re: svn icons in the toolbar

[Richard Stallman]

    I am not familiar with the KDE icon API but I briefly searched the
    docs on my system as well as the web and couldn't find anything for
    KDE icons that seems similar to GNOME's stock icons.

That is too bad.

Re: svn icons in the toolbar

[Frank Schmitt]

Richard Stallman <rms@gnu.org> writes:

>     I am not familiar with the KDE icon API but I briefly searched the
>     docs on my system as well as the web and couldn't find anything for
>     KDE icons that seems similar to GNOME's stock icons.
>
> That is too bad.

I think there is a common standard supported by both gnome and KDE which
is developed by the Tango project at freedesktop.org (see
http://tango.freedesktop.org/Tango_Desktop_Project contact at
xdg@lists.freedesktop.org)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: svn icons in the toolbar

[Stephen Berman]

On Tue, 25 Sep 2007 13:43:52 +0200 Frank Schmitt <ich@frank-schmitt.net> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>>     I am not familiar with the KDE icon API but I briefly searched the
>>     docs on my system as well as the web and couldn't find anything for
>>     KDE icons that seems similar to GNOME's stock icons.
>>
>> That is too bad.
>
> I think there is a common standard supported by both gnome and KDE which
> is developed by the Tango project at freedesktop.org (see
> http://tango.freedesktop.org/Tango_Desktop_Project contact at
> xdg@lists.freedesktop.org)

I see that the Tango Standard Icon Naming Specification proposes a
classification of icon types and standard icon names that KDE and
GNOME both more or less use.  What I don't see in KDE is any naming
scheme like GNOME's stock* or gtk* icons.  It looks like these are
often aliases for icon names conforming to the Tango Standard Icon
Naming Specification.  I don't know what criteria GNOME uses to call
certain icons stock icons, nor just what role these play in the GNOME
icon API.  The Tango website also says: "In the short term, existing
KDE and GNOME icons names will be addressed using symlinks. We have
prepared a script which automatically generates appropriate symlinks
for existing naming schemes in GNOME and KDE so that compatibility
with current desktop applications will be preserved."  I have no idea
if this makes sense, but maybe this script could somehow be used or
adapted by Emacs to map GTK+ to Qt/KDE icons.

Steve Berman

Re: svn icons in the toolbar

[Jan Djärv]

Stephen Berman skrev:

> 
> I see that the Tango Standard Icon Naming Specification proposes a
> classification of icon types and standard icon names that KDE and
> GNOME both more or less use.  What I don't see in KDE is any naming
> scheme like GNOME's stock* or gtk* icons.  It looks like these are
> often aliases for icon names conforming to the Tango Standard Icon
> Naming Specification.  I don't know what criteria GNOME uses to call
> certain icons stock icons, nor just what role these play in the GNOME
> icon API.

I guess that it is being present in Gtk+ that makes them "stock".

> The Tango website also says: "In the short term, existing
> KDE and GNOME icons names will be addressed using symlinks. We have
> prepared a script which automatically generates appropriate symlinks
> for existing naming schemes in GNOME and KDE so that compatibility
> with current desktop applications will be preserved."  I have no idea
> if this makes sense, but maybe this script could somehow be used or
> adapted by Emacs to map GTK+ to Qt/KDE icons.
> 

Would it not be better to figure out a set of named icons that either can be 
used on both KDE and Gnome (I guess this is what Tango is about) or add a KDE 
specific set of names to Emacs?  Users can then select to use the KDE names if 
they run KDE.

	Jan D.

Re: svn icons in the toolbar

[Richard Stallman]

    Would it not be better to figure out a set of named icons that either can be 
    used on both KDE and Gnome (I guess this is what Tango is about) or add a KDE 
    specific set of names to Emacs?  Users can then select to use the KDE names if 
    they run KDE.

It would be better to put in a translation table from GNOME stock
names to corresponding KDE names.  Then you could tell Emacs to apply
this set of translations, if you need it.

Emacs could even try automatically to use these translations, if
it discovers any problem with using the GNOME icons or names.

Re: svn icons in the toolbar

[Dan Nicolaescu]

Stephen Berman <Stephen.Berman@gmx.net> writes:

  > On Thu, 20 Sep 2007 12:35:17 -0400 Richard Stallman <rms@gnu.org> wrote:
  > 
  > >     Hmm, pity.  I wonder if there is a workaround, some way to get the
  > >     named icons on to the tool bar under KDE that circumvents the Gnome
  > >     settings daemon.
  > >
  > > Do you mean, despite the absence of the GNOME settings daemon?
  > > I agree.
  > 
  > In my case it is the gtk-qt engine that regulates the choice of
  > theme-related icons via a mapping from the GTK+ icons.  I don't know
  > the details of gtk-qt but I assume it doesn't use the GNOME settings
  > daemon. 
  > 
  > > Does KDE have any concept of standard icons?
  > 
  > I am not familiar with the KDE icon API but I briefly searched the
  > docs on my system as well as the web and couldn't find anything for
  > KDE icons that seems similar to GNOME's stock icons.


Do other gnome applications like gedit for example find the correct
icons? gedit ought to use some of the same icons that emacs is trying
to use.

gmm-tool-bar-style (was: svn icons in the toolbar)

[Reiner Steib]

On Thu, Sep 02 2007, Leo wrote:
> Have you noticed that the tool-bar in Gnus's article buffer, summary
> buffer and message buffer has gone back to using the old-fashioned icons
> or missing a couple of icons. See:
[ Screen shots, see http://article.gmane.org/gmane.emacs.devel/77591 ]

On Thu, Sep 06 2007, Leo wrote:
> My Emacs was installed from a fresh CVS check out on the first build
> which you can see from 23.0.50.1.
>
> Toobar and menubar are initially disabled.
> Emacs.menuBar: 0
> Emacs.toolBar: 0

[ -xrm 'Emacs.toolBar:0' ]

> Turn on tool-bar-mode and switch to gnus buffers and you can see the
> weird tool-bar shown up.

I think similar problems appear with Emacs 22.1.  

Maybe the bug is the default value of `gmm-tool-bar-style':

--8<---------------cut here---------------start------------->8---
(defcustom gmm-tool-bar-style
  (if (and (boundp 'tool-bar-mode)
	   tool-bar-mode
	   (and (fboundp 'display-visual-class)
		(not (memq (display-visual-class)
			   (list 'static-gray 'gray-scale
				 'static-color 'pseudo-color)))))
      'gnome
    'retro)
  "Prefered tool bar style."
  :type '(choice (const :tag "GNOME style" gnome)
		 (const :tag "Retro look"  retro))
  :group 'gmm)
--8<---------------cut here---------------end--------------->8---

I don't exactly remember what I had in mind with testing for non-nil
`tool-bar-mode'.  Could you try the following patch?

--8<---------------cut here---------------start------------->8---
--- gmm-utils.el	27 Apr 2007 10:39:17 +0200	7.33
+++ gmm-utils.el	26 Sep 2007 22:01:11 +0200	
@@ -208,7 +281,6 @@
 
 (defcustom gmm-tool-bar-style
   (if (and (boundp 'tool-bar-mode)
-	   tool-bar-mode
 	   (and (fboundp 'display-visual-class)
 		(not (memq (display-visual-class)
 			   (list 'static-gray 'gray-scale
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: svn icons in the toolbar

[Stephen Berman]

An update:

On Wed, 19 Sep 2007 23:22:58 +0200 Stephen Berman
<Stephen.Berman@gmx.net> wrote: 

> On Wed, 19 Sep 2007 08:26:24 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>> Stephen Berman skrev:
>>> On Sun, 02 Sep 2007 19:46:52 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>>> Jan Djärv skrev:
>>>>> Leo skrev:
>>>>>> However have you noticed the 3rd icon on the tool-bar is still from the
>>>>>> old xpm images. A new one could look like this:
>>>>>>
>>>>> Yes, I've noticed.  That is because I found no suitable stock icon for it.
>>>>> Does the icon you attached have a stock name?  Where is it from?
>>>>>
>>>> I think it is the named icon system-file-manager.  I added that one.
>>>
>>> I'm running GNU Emacs 23.0.50.3 (i686-pc-linux-gnu, GTK+ Version
>>> 2.10.6) of 2007-09-17 on escher under KDE 3.5.7.  The defcustom
>>> x-gtk-stock-map from x-win.el contains this: ("etc/images/diropen"
>>> . "n:system-file-manager").  Nevertheless, the relevant tool bars all
>>> have diropen.xpm from etc/images rather than system-file-manager.png.
>>> My system has the following system-file-manager icons:
>>>
>>>     /opt/gnome/share/icons/gnome/16x16/apps/system-file-manager.png
>>>     /opt/gnome/share/icons/gnome/22x22/apps/system-file-manager.png
>>>     /opt/gnome/share/icons/gnome/24x24/apps/system-file-manager.png
>>>     /opt/gnome/share/icons/gnome/32x32/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/128x128/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/16x16/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/22x22/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/24x24/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/32x32/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/48x48/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/64x64/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/72x72/apps/system-file-manager.png
>>>     /usr/share/icons/Tango/96x96/apps/system-file-manager.png
>>>
>>> When I run Emacs under Gnome, system-file-manager.png is used.  Note
>>> that the tool bars do display the available Gnome stock icons under
>>> KDE, it's just the named icon that isn't used.
>>>
>>
>> I don't think named icons work under anything else than Gnome.  The
>> theme is set in XSETTINGS and that is maintained by the gnome settings
>> daemon.  The Gtk+ stock icons however, are hardcoded in Gtk+.
>
> I forgot that I am using the gtk-qt engine, which "allows GTK
> applications to use Qt widget styles", including tool bar icons.  The
> icons I see are actually KDE icons from
> /opt/kde3/share/icons/crystalsvg/32x32/actions.  I assume gtk-qt maps
> the Gnome stock icons to corresponding KDE icons of the selected
> theme.  I couldn't find an icon in the crystal theme corresponding to
> system-file-manager, but it may just be that gtk-qt does not handle
> named Gnome icons.
>
> Steve Berman

I recently installed openSUSE 10.3 and there I do see the named
system-file-manager icon in the tool bar under KDE.  I would guess this
is due to an updated gtk-qt engine, but I haven't tried the latest
gtk-qt engine in openSUSE 10.2.  I did look at gtk-qt source and was
surprised to find no reference to system-file-manager, but maybe it's
referred to differently or I just don't understand how the mapping is
done.  Whatever, at least I see the icon now.  Hopefully I'll still be
able to after the bug that the code to handle named icons introduced
(see my post about Emacs aborting with a detached GTK+ tool bar) is
fixed!

Steve Berman