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 608175 - Needs to expose more headers, and fix include paths in others
Needs to expose more headers, and fix include paths in others
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.30.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2010-01-26 17:52 UTC by Gustavo Noronha (kov)
Modified: 2013-09-13 01:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
expose ECalendarSelector, and the calendar importer (1.30 KB, patch)
2010-01-26 17:53 UTC, Gustavo Noronha (kov)
committed Details | Review
make authentication available as well (808 bytes, patch)
2010-01-26 17:53 UTC, Gustavo Noronha (kov)
none Details | Review
fix include paths for a number of headers (2.11 KB, patch)
2010-01-26 17:54 UTC, Gustavo Noronha (kov)
committed Details | Review
Make calendar authentication functionality available to API users (25.30 KB, patch)
2010-01-26 19:04 UTC, Gustavo Noronha (kov)
committed Details | Review

Description Gustavo Noronha (kov) 2010-01-26 17:52:35 UTC
While building a stand-alone calendar application (which is now hosted here: http://git.gnome.org/browse/annum/), I hit some problems with headers not being available, or making the build fail because they use include paths that are only valid inside the Evolution source tree. If some of those should not be exposed let me know, and I'll consider shipping the relevant parts in the application itself. Patches attached.
Comment 1 Gustavo Noronha (kov) 2010-01-26 17:53:14 UTC
Created attachment 152325 [details] [review]
expose ECalendarSelector, and the calendar importer
Comment 2 Gustavo Noronha (kov) 2010-01-26 17:53:40 UTC
Created attachment 152326 [details] [review]
make authentication available as well
Comment 3 Gustavo Noronha (kov) 2010-01-26 17:54:04 UTC
Created attachment 152327 [details] [review]
fix include paths for a number of headers
Comment 4 Gustavo Noronha (kov) 2010-01-26 18:41:12 UTC
(In reply to comment #3)
> Created an attachment (id=152327) [details] [review]
> fix include paths for a number of headers

Pushed as 65305b728467e74a22300be78cbf498fc5213973.
Comment 5 Gustavo Noronha (kov) 2010-01-26 19:04:53 UTC
Created attachment 152331 [details] [review]
Make calendar authentication functionality available to API users

This patch adds the e_ prefix. Evo keeps building, and so does my application after making the appropriate changes to it =).
Comment 6 Matthew Barnes 2010-01-26 20:12:23 UTC
Not that it's a show-stopper, but why does evolution-calendar-importer.h need to be installed?
Comment 7 Gustavo Noronha (kov) 2010-01-26 20:28:03 UTC
(In reply to comment #6)
> Not that it's a show-stopper, but why does evolution-calendar-importer.h need
> to be installed?

The application I'm writing should be usable without having Evolution around. I am writing it using EShell* objects as a base, but I not always need or want everything that is done by their constructor/constructed methods, which is why I don't just chain up. For that reason, in my EShellBackend I have to initialize the importers:

static void annum_shell_backend_init_importers (void)
{
        EImportClass *import_class;
        EImportImporter *importer;

        import_class = g_type_class_ref (e_import_get_type ());

        importer = gnome_calendar_importer_peek ();
        e_import_class_add_importer (import_class, importer, NULL, NULL);

        importer = ical_importer_peek ();
        e_import_class_add_importer (import_class, importer, NULL, NULL);

        importer = vcal_importer_peek ();
        e_import_class_add_importer (import_class, importer, NULL, NULL);
}

Having said that, this is not a functionality I have invested in yet, so I can come back to this specific issue when I reach it, if you prefer.
Comment 8 Matthew Barnes 2010-01-26 21:05:13 UTC
Understand.  I'd rather not install the import headers, so let's leave that out for now and I can help you work around it if need be.  Eventually I'd like to rewrite the whole import framework such that calendar importers are loaded automatically with libevolution-calendar.so.  Similarly with mail importers, etc.
Comment 9 Gustavo Noronha (kov) 2010-01-26 22:00:39 UTC
(In reply to comment #8)
> Understand.  I'd rather not install the import headers, so let's leave that out
> for now and I can help you work around it if need be.  Eventually I'd like to
> rewrite the whole import framework such that calendar importers are loaded
> automatically with libevolution-calendar.so.  Similarly with mail importers,
> etc.

Sounds good. What about ECalendarSelector, and the auth patch? =)
Comment 10 Matthew Barnes 2010-01-26 23:14:31 UTC
Go ahead and commit them -- except for the importer file.  Don't have time to do a test build with it right now but if anything breaks I'll take care of it.
Comment 11 Gustavo Noronha (kov) 2010-01-27 13:27:30 UTC
Comment on attachment 152331 [details] [review]
Make calendar authentication functionality available to API users

Pushed as d635b839f8d22746f44067464dc3c645aeeb8591.
Comment 12 Gustavo Noronha (kov) 2010-01-27 13:40:55 UTC
Comment on attachment 152325 [details] [review]
expose ECalendarSelector, and the calendar importer

Pushed as dcc317e6496327fb87378985fb731bfe31782871, with ECalendarSelector being exposed, only.
Comment 13 Gustavo Noronha (kov) 2010-01-27 13:41:39 UTC
Thanks for the reviews, Matthew, I tested Evo's build, and my application keeps working as well.