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 465473 - Lack of a libebookui
Lack of a libebookui
Status: RESOLVED WONTFIX
Product: evolution-data-server
Classification: Platform
Component: Contacts
unspecified
Other All
: Normal enhancement
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-08-10 18:39 UTC by Snark
Modified: 2015-06-03 09:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Snark 2007-08-10 18:39:43 UTC
Evolution has a contact editing window, so does openedhand's contacts program -- both based on evolution-data-server.

The current situation is that libedataserverui provides ui tools for (mostly) libedataserver and a little for libebook, but not that much -- and this is where the code duplication stems from.

It should be possible to share this code in a common libebookui, which all projects using e-d-s would then use.
Comment 1 Ross Burton 2007-08-10 18:51:35 UTC
The main problem would be coming up with an interface.  I'm sure Evolution wouldn't want Contacts's editor UI, Evolution's editor UI plain won't fit in Contacts, and we've a new development branch of Contacts with another UI.

The best thing really would be a contact object that doesn't actively make writing an editor hard (like EContact and EVCard do).
Comment 2 Snark 2007-08-10 19:10:32 UTC
I indeed saw EContact/EVCard are not really live objects -- more like dead structures, but wouldn't the following scheme give acceptable results :
(1) create a window with the EBook and the contact id ;
(2) the window then lets the user edit things ;
(3) on confirmation, it commits ;
(4) the signals will then update the views?
Comment 3 Ross Burton 2007-08-10 19:39:08 UTC
(2) is the hard bit, which changes per-application.  The rest of the logic is about 10 lines.
Comment 4 Snark 2007-08-11 05:58:43 UTC
I don't exactly get why it would change per-application : the applications currently care very much about what the user can edit or not precisely because they have to implement it themselves!

If they were given a window they can use in ten lines, wouldn't they use it? As long as the door is left open for more specialized implementations in projects which really, really, really need it, I don't think people will mind that much...
Comment 5 Snark 2007-08-20 19:48:05 UTC
Well, this idea keeps crawling in my head. I would say it is better to have a handy default (which people can decide not to use), than propose nothing and have everyone be forced to code half-solutions.
Comment 6 Milan Crha 2015-06-03 09:58:18 UTC
I'm WontFix-ing this. While code duplication is bad, the applications use their own UI which may not fix across them for various reasons. Having the editors out there is not useful. Also, during the years, the libedataserverui was completely removed, then re-added for 3.16.0 with a very limited functionality.