GNOME Bugzilla – Bug 332496
Category icons not removable
Last modified: 2009-11-10 15:55:49 UTC
After assigning an icon to a Category, there is no way to remove this icon. Steps to reproduce: * Edit any Contact, just to be able to... * Edit any Category. Assign an icon to the Category. Save it. Now try to remove this icon...
confirming.
"No Image" button is reqd. like we have in photo for contacts.
contact photos are removable, patch should be very similar.
see addressbook/gui/contact-editor/e-contact-editor.c
I tried to do this this afternoon by modifying e-d-s/libedataserverui/e-categories-dialog.c but it seems I couldn't get it for the moment. I tried to replace line 97: prop_dialog->category_icon = glade_xml_get_widget (prop_dialog->gui, "category-icon"); by a self-made GtkFileChooserButton like this : GtkWidget *file_selector = gtk_file_chooser_dialog_new ( _("Choose an icon"), GTK_WINDOW (prop_dialog->the_dialog), GTK_FILE_CHOOSER_ACTION_OPEN, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT, _("No Image"), GTK_RESPONSE_NO, NULL); gtk_window_set_modal (GTK_WINDOW (file_selector), TRUE); gtk_window_set_destroy_with_parent(GTK_WINDOW (file_selector), FALSE); prop_dialog->category_icon = gtk_file_chooser_button_new_with_dialog(GTK_WIDGET(file_selector)); From what I understand, gtk_file_chooser_button_new_with_dialog should create a GtkFileChooserButton using the previous GtkFileChooser I created but it doesn't. Any clue would be appreciated.
Gilles, Sorry I didnt get what you asked. But as I have said earlier the gtk file chooser should have a button 'No Image' which should remove the image associated with the category.
What I'm trying to say is that I instead of getting a GtkFileChooserButton from the glade file which is not modifiable after creation (meaning we can't add a button). So I tried to create a GtkFileChooserDialog that can be associated to a GtkFileChooserButton so that we get what we want. The relevant line is : prop_dialog->category_icon = gtk_file_chooser_button_new_with_dialog(GTK_WIDGET(file_selector)); file_selector has a "No Image" button obviously. From my understanding it should just create what I've described but it seems it doesn't. I may have missed something though. I forced the displaying of file_selector to see if it was correct and it is. I'll see the gtk+ sources to see if something's wrong there.
An easier way is to declare that as a custom widget and you create a gtkfilechooser button on the creation call.
Bumping version to a stable release.
Created attachment 123814 [details] test thing Making GtkFileChooserButton showing "(None)" seems to be quite impossible after had some file selected. I'll file a bug against gtk+ to extend this and let's see.
Created attachment 123874 [details] [review] proposed eds patch for evolution-data-server; requires patch from the bug #563010.
This is a great solution for the long-term, but we can't use new GTK+ API until it's included in a stable GNOME release, which won't happen until next fall at the earliest.
I was told that with a little bit luck they'll include it to 2.14, as an API extension, not modification. But will see.
The patch otherwise seems fine to me. I have told Matt sometime back, that we will stick to Gtk+ 2.14 or atleast make it compile on 2.14 for some time, through IFDEF. Off-late I heard lots of concerns from people that they aren't unable to use new-er evolution, as we stick to the latest-stable which isn't available to them. Most of those people are in the enterprise (SLE/RHE/Etc) releases, which sticks to older platforms. I'm fine to adapt to new Gtk+/Glib, but make it a #ifndef GTK_2_16 for some time. We could do the clean-up over a period of time. Thatz my thought.
See bug #380534 for historical perspective. Also has a link to some mailing list discussion. I'm fine with delaying requiring a new library version for one extra development cycle, but we really need to be able to utilize new GNOME technologies as they become available in order to stay relevant. Frankly, enterprise users trying to run the latest release on a 2+ year old platform doesn't concern me. Evolution is first and foremost a GNOME component and GNOME's progress should not be slowed by enterprise platforms.
Matt, I meant that lets adapt to new ones with a option to leave it for the old users under a IFDEF, even though its a bit buggier in those cases. My thought would be to take/merge once in ~3-4 releases. That should typically take care of most enterprise releases.
(In reply to comment #14) > Most of those people are in the enterprise (SLE/RHE/Etc) releases It's the task of distributors to port apps if they want to ship newer releases. It's nothing I want to see considered upstream to slow down development.
Andre, So Im saying lets mae it possible to compile, by leaving things with-in #ifdef OLD_GTK #endif foo. I'm on for depending on the latest stable, no change with that, but lets try to have it supported for even more old releases.
Hrm, the gtk bug is still waiting its decision, bad.
Created attachment 147385 [details] [review] eds patch for evolution-data-server; This is an updated patch for master. Note it will work only if your gtk+ is 2.18.4 and later (see bug #563010 comment #22)
Created commit f4a4db4 in eds master (2.29.2+)