GNOME Bugzilla – Bug 514041
Add space between categories
Last modified: 2021-05-19 12:13:30 UTC
(This is an insignificant bug...) In the Contacts, define a new view, based on Card View, and allow field Categories. Then look at a person who has associated two or more categories: between the categories ins't a space. For example: "Friends,Work,Family" (not "Friends, Work, Family"). In think that the space is behind the char "," in all typographical rules in the world because it's better to reading. Other information:
Created attachment 155856 [details] EDS Patch While returning category list it returns coma and space separated list.
Comment on attachment 155856 [details] EDS Patch diff --git a/addressbook/libebook/e-contact.c b/addressbook/libebook/e-contact.c index 974c4c1..e5edfed 100644 --- a/addressbook/libebook/e-contact.c +++ b/addressbook/libebook/e-contact.c @@ -1528,14 +1528,14 @@ e_contact_get (EContact *contact, EContactField field_id) g_string_append (str, (gchar *)v->data); v = v->next; if (v) - g_string_append_c (str, ','); + g_string_append (str, ", "); + } rv = g_string_free (str, FALSE); } return rv; - break; - } + } default: g_warning ("unhandled synthetic field 0x%02x", info->field_id); break;
Created attachment 155930 [details] [review] EDS Patch While returning category list it returns coma and space separated list, break is not needed so i removed it.
Thanks for a patch. It seems to work as requested, but I've a feeling that it's not a good thing to do it this way, because the RFC 2426 [1] says the CATEGORIES is a list of values separated by comma, not by comma and space. I know you changed only the e_contact_get function, and that the e_contact_set function expects leading spaces and removes them, but I'm wondering whether some other libraries/applications using EContact wouldn't be in trouble with this change, when expecting its value as defined by the RFC (I mean some synchronization applications, for example, if any is using EContact and not EVCard). Please also note of bug #600527. If at all, then the change should be done on evolution side, in the UI part, not so deep in the library. The change might be done for a minicard view, the list view, and also the list view for calendar/tasks/memos, to have this consistent. From my point of view the editing dialogs can be without spaces, it doesn't matter much there, because you'll click the "Categories:" button anyway. So if you can, please try to do the other approach. It'll be pretty similar like here, only on more places in evolution code base. Thanks. [1] http://tools.ietf.org/html/rfc2426#section-3.6.1
What the UI should accept and what the RFC dictates are completely separate things. Users should not need to know about RFC syntax. Instead we should read the user-input and reformat it to comply with the RFC.
(In reply to comment #5) > What the UI should accept and what the RFC dictates are completely separate > things. Users should not need to know about RFC syntax. Instead we should > read the user-input and reformat it to comply with the RFC. Of course. And 'we', aka Evolution, does that. Does that also any other library/application using e_contact_get with categories? If so, or if we do not "care", then yes, the patch can be used. I only didn't want to "break" behaviour of the function for categories if anyone is expecting it to return value in a particular format. Maybe a nonsense on my side, feel free to approve the patch, Matt.
I'll commit your change to master. No need to be paranoic as that much as I am.
Created commit 17dd871 in eds master (2.31.1+)
While porting evolution-kolab from 2.30 to 3.3.2 (on the way to 3.4), I just got bitten by this, so I'm re-opening. The Kolab format specification mandates that a field which has not changed must be written back onto the server _verbatim_, this is, _unchanged_. This is for client interop and to not mess with sync states Kolab clients may implement in their very own way. This change introduces a problem for me: When writing a non-NULL categories field back onto the server, which has not been changed in Evo, I cannot tell whether the field came from the server in RFC-compliant format or whether some client applied some differing formatting before, which I must preserve, unless I really *change* the contents of the field ('I' means 'a Kolab client' here). IMHO, EContact should retain the strings verbatim, not applying any changes to them just for beautification. Just how the list is *displayed* is a completely different matter and should be left to some frontend like Evolution. The only way for me to not be a broken Kolab client in this regard would be to introduce a hidden field, into which I would need to save the original string. Before converting the EContact back into Kolab XML, I would need to strip the blanks after the commas in both strings, compare them, and if they do not differ, write the previously saved and hidden verbatim copy back into the Kolab XML, just to retain its original formatting. That's cumbersome. The simpler way would be to just not touch the string in EContact unless it is really edited (this is, changed).
I suggest adding an ECategoryEntry widget to libedataserverui for parsing user-input and formatting the category list for display. Keep the API generic (e.g. string arrays) so we can reuse it for contacts and calendar components. Similar in concept to ENameSelectorEntry for entering email addresses in the composer.
I reverted the change in sources till the Matthew's proposal will not reach code base. Created commit a73166f in eds master (3.3.3+) Created commit d15bdd0 in eds gnome-3-2 (3.2.3+)
Thanks Milan and Matt. Your initial gut feelings about that change were correct. I'm very sure that separating displaying and storing of data and have EContact and friends not touch the data in their getter/setter functions is the right route to take. It is not really different from, say, Email rendering vs. Email storing (aside from the fact that mail data is not really *edited*). The Camel(Mime)Message handles *storage* format, not *display* format. My guess is that also SyncEvolution and the like will benefit from E<PIM-Type> implementations with a neutral behaviour.
(In reply to comment #10) > I suggest adding an ECategoryEntry widget to libedataserverui for parsing > user-input and formatting the category list for display. Keep the API generic > (e.g. string arrays) so we can reuse it for contacts and calendar components. > > Similar in concept to ENameSelectorEntry for entering email addresses in the > composer. As noted in bug #663324, comment #30: it would be good to order the categories displayed by ECategoryEntry alphabetically. This will allow users to scan them for a given category slightly faster.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.