After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660917 - background image does not work
background image does not work
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Charting
git master
Other Linux
: Normal normal
: ---
Assigned To: Jean Bréfort
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-10-04 19:30 UTC by Frédéric Parrenin
Modified: 2011-10-28 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screen shot of chart properties dialog section (5.39 KB, image/png)
2011-10-04 20:44 UTC, Andreas J. Guelzow
Details
dialog after adding a file...? (14.32 KB, image/png)
2011-10-04 20:45 UTC, Andreas J. Guelzow
Details
screenshot showing some issues (37.92 KB, image/png)
2011-10-05 20:48 UTC, Andreas J. Guelzow
Details
screen shot of image selector (14.54 KB, image/png)
2011-10-05 20:57 UTC, Andreas J. Guelzow
Details
screen shot showing spacing issues (22.53 KB, image/png)
2011-10-05 21:00 UTC, Andreas J. Guelzow
Details

Description Frédéric Parrenin 2011-10-04 19:30:41 UTC
It is possible to select an image but the image is not draw as background.
Comment 1 Jean Bréfort 2011-10-04 19:53:04 UTC
Seems the dialog is broken.
Comment 2 Jean Bréfort 2011-10-04 20:28:10 UTC
Actually things do work. You must first add an image to the document, choosing both a name and a file, and click the Add button. Then you can select the image by clicking on the thumbnail. I agree that it is not very intuitive.
Comment 3 Andreas J. Guelzow 2011-10-04 20:43:56 UTC
@Jean,

there are some issues though:

The "Fit" combo is unnaturally high
The icon to the right of the Fit combo and Select button seems out of place.

If I click Select and again Select in the next dialog, choose a file and okay I end up at a dialog that hasn't changed. Clicking on Add, adds a tiny square in the top area... ???  What is that top white area goof for anyways.

Note that Add button should really only be active when it really does something. When I type a name and select a file, the dialog does not show that I selected a file and clicking the add button just deletes the name!

I will be adding to screen shots.
Comment 4 Andreas J. Guelzow 2011-10-04 20:44:41 UTC
Created attachment 198250 [details]
screen shot of chart properties dialog section
Comment 5 Andreas J. Guelzow 2011-10-04 20:45:20 UTC
Created attachment 198253 [details]
dialog after adding a file...?
Comment 6 Andreas J. Guelzow 2011-10-04 20:46:58 UTC
If I add an image to the document, shouldn't that image be available for other fills?
Comment 7 Andreas J. Guelzow 2011-10-04 20:57:07 UTC
And if you first insert the chart and then open it to add an image fill, there seem to be no sequence of actions that successfully adds the image fill.
Comment 8 Jean Bréfort 2011-10-04 21:02:13 UTC
OK, I need to investigate all these issues.
Comment 9 Jean Bréfort 2011-10-05 18:25:03 UTC
Pushed a fix. Please test again.
Comment 10 Frédéric Parrenin 2011-10-05 20:38:10 UTC
Hi! OK, I now see how it works. Still, I find the sequence very complicate:
- why should we provide a name for the image? This really makes things more complex, because you cannot add an image when there is no name. At least, a message should inform the user about this.
- and even, why is it not possible to go directly in the file selection dialog? It is what I was expecting.
Comment 11 Andreas J. Guelzow 2011-10-05 20:46:33 UTC
I guess the idea is that you are likely to use the same image for fills in several graphs (or several parts of one or more graphs). So it is simpler to keep a listing of the images already imported into the document. 

When you are using an image as a fill you are not just specifying a file name but in fact are importing the fill into the document proper.

(I would agree that there are lots of ways this could be improved!)
Comment 12 Andreas J. Guelzow 2011-10-05 20:48:47 UTC
Created attachment 198377 [details]
screenshot showing some issues

Problems I see here:

The Type, Fit etc. should really be immediately below the "Fill" header.

The tiny icon is not understandable. Wouldn't it be better to simply say that no image is selected?!
Comment 13 Andreas J. Guelzow 2011-10-05 20:57:27 UTC
Created attachment 198379 [details]
screen shot of image selector

I see several issues with this dialog:

The primary item seems to be the "Add"... when it is really the listing at the top.

If I select an image and then add a name the Add button stays insensitive. IT seems to become sensitive only if a first specify a name and then select the image. (Upon selection of an image we should probably construct a default name!)

If I add an image the dialog does not change, so I am never sure whether I in fact selected one for addition or not...

The ok button should not be active unless a image is in fact selected!
Comment 14 Andreas J. Guelzow 2011-10-05 21:00:28 UTC
Created attachment 198380 [details]
screen shot showing spacing issues

there are clearly some spacing issues....
Comment 15 Andreas J. Guelzow 2011-10-05 21:06:09 UTC
How do I delete an image from the list once I don't use it anymore for a fill?
Comment 16 Jean Bréfort 2011-10-09 13:04:28 UTC
(In reply to comment #12)
> Created an attachment (id=198377) [details]
> screenshot showing some issues
> 
> Problems I see here:
> 
> The Type, Fit etc. should really be immediately below the "Fill" header.

Looks like one more gtk3 issue. Looks like gtk3 has issues when dealing with boxes and alignments inside each other.

> The tiny icon is not understandable. Wouldn't it be better to simply say that
> no image is selected?!

Agreed.
Comment 17 Jean Bréfort 2011-10-09 13:06:40 UTC
Do we really need to delete images, we might just not save those that are not in use (which is not currently the case).
Comment 18 Andreas J. Guelzow 2011-10-11 14:56:28 UTC
If we do not save (and do not show) images that are not in use, we obviously do not need a "delete", but the latter is required otherwise.
Comment 19 Jean Bréfort 2011-10-11 15:12:39 UTC
They will still show up in the list. Even adding a "delete" button needs a way to know if the image is actually used, otherwise we'll most probably get crashes. I'll add go_image_ref and go_image_unref.
Btw, I'm currently trying to redesign the whole GOImage code in order to properly support svg (and possibly other vectorial drawings).
Comment 20 Jean Bréfort 2011-10-16 14:05:52 UTC
Actually unused images are not saved.
Comment 21 Jean Bréfort 2011-10-17 08:13:44 UTC
After more thinking, I believe that we actually don't need the "Add" button. If a file is selected, we should just add the new image to the doc with an automatic name if none is provided. This would make things easier, I suppose.
Comment 22 Andreas J. Guelzow 2011-10-17 20:07:36 UTC
Jean, I agree. I think the first dialog should just give a list with the already added images and an "Other" button. The file selector started from the "Other button" could then include a name entry that is being pre-populated with the file name (+/- a counter).
Comment 23 Jean Bréfort 2011-10-21 12:32:33 UTC
I redesigned the image selector. May be we might request a larger size since only one thumbnail is visible at once with the default size. Please check.

This leave the fill style page issues (comment #16).
Comment 24 Andreas J. Guelzow 2011-10-21 19:53:51 UTC
I think this is a great improvement, but why, after selecting a new image, am I returned to the image selector? Since I just selected the image I want to use I should go directly back to the graph guru.
Comment 25 Andreas J. Guelzow 2011-10-21 19:57:31 UTC
Also double clicking an image should really close teh dialog with that image selected.

More importantly:

Clicking twice (?) in the window close box of the image selector yields:

Program received signal SIGSEGV, Segmentation fault.
__libc_free (mem=0x4066e201) at malloc.c:3709
3709	malloc.c: No such file or directory.
	in malloc.c

  • #0 __libc_free
    at malloc.c line 3709
  • #1 g_free
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #2 delete_event_cb
    at go-image-sel.c line 138
  • #3 _gtk_marshal_BOOLEAN__BOXED
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkmarshalers.c line 85
  • #4 g_closure_invoke
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #5 ??
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #6 g_signal_emit_valist
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #7 g_signal_emit
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #8 gtk_widget_event_internal
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkwidget.c line 6106
  • #9 gtk_main_do_event
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkmain.c line 1774

Comment 26 Andreas J. Guelzow 2011-10-21 19:59:34 UTC
clicking once in the window close box of the image selector and then the okay button yields:

Program received signal SIGSEGV, Segmentation fault.
0xb768dcd0 in gtk_icon_view_get_selected_items (icon_view=0x9e)
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkiconview.c:5263
5263	/build/buildd/gtk+3.0-3.0.8/./gtk/gtkiconview.c: No such file or directo

  • #0 gtk_icon_view_get_selected_items
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkiconview.c line 5263
  • #1 ok_button_clicked_cb
    at go-image-sel.c line 147
  • #2 g_cclosure_marshal_VOID__VOID
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #3 g_closure_invoke
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #4 ??
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #5 g_signal_emit_valist
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #6 g_signal_emit
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #7 gtk_button_clicked
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkbutton.c line 1194
  • #8 gtk_real_button_released
    at /build/buildd/gtk+3.0-3.0.8/./gtk/gtkbutton.c line 1827
  • #9 g_cclosure_marshal_VOID__VOID
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0

Comment 27 Jean Bréfort 2011-10-22 08:45:15 UTC
Issues described in comments #24-26 are (hopefully) fixed.
Comment 28 Jean Bréfort 2011-10-28 10:08:37 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

Looks like every thing works fine now. Feel free to reopen if you don't agree…