1. 13 Mar, 2019 1 commit
  2. 31 Oct, 2018 1 commit
  3. 14 Jun, 2018 1 commit
  4. 17 May, 2018 1 commit
  5. 11 Oct, 2016 1 commit
  6. 10 Oct, 2016 1 commit
  7. 01 Jun, 2015 1 commit
  8. 28 Apr, 2015 1 commit
  9. 17 Oct, 2014 1 commit
  10. 28 Feb, 2014 1 commit
  11. 07 Jan, 2014 1 commit
  12. 11 Nov, 2013 1 commit
  13. 08 Jun, 2013 1 commit
  14. 07 Jun, 2013 1 commit
  15. 19 May, 2013 2 commits
  16. 06 May, 2013 1 commit
  17. 06 Mar, 2013 1 commit
  18. 01 Feb, 2013 2 commits
    • Matthew Barnes's avatar
      Add a priority field for mail formatter and parser extensions. · ce3d24ef
      Matthew Barnes authored
      Add a priority field to EMailFormatterExtension and EMailParserExtension
      class structs.  Extension classes can then explicitly specify a priority
      with respect to other extension classes with the same MIME type, so that
      the order of extension registration doesn't matter.
      Priority field defaults to G_PRIORITY_DEFAULT.  Built-in formatters and
      extensions will use G_PRIORITY_LOW.  We can get more sophisticated with
      priority values if we need to, but this should suffice for now.
    • Matthew Barnes's avatar
      Teach EMailExtensionRegistry to find extensions. · 9a0b1266
      Matthew Barnes authored
      Restore this commit with a proper bug fix to follow.
  19. 29 Jan, 2013 1 commit
    • Milan Crha's avatar
      Revert "Teach EMailExtensionRegistry to find extensions." · 57adde4b
      Milan Crha authored
      This reverts commit bf30024d, because
      it breaks EMailFormatter/Parser extensions, like the prefer-plain.
      The thing is that the internal formatters/parsers (also extensions)
      should be always added first, and only after then can be added extended
      extensions, which are used before those internal. This constraint was not
      satisfied with the reverted commit, the order of extension registration
      was unpredictable, depended on GType.
  20. 12 Dec, 2012 1 commit
    • Matthew Barnes's avatar
      Consolidate base utility libraries into libeutil. · d09d8de8
      Matthew Barnes authored
      Evolution consists of entirely too many small utility libraries, which
      increases linking and loading time, places a burden on higher layers of
      the application (e.g. modules) which has to remember to link to all the
      small in-tree utility libraries, and makes it difficult to generate API
      documentation for these utility libraries in one Gtk-Doc module.
      Merge the following utility libraries under the umbrella of libeutil,
      and enforce a single-include policy on libeutil so we can reorganize
      the files as desired without disrupting its pseudo-public API.
      This also merges libedataserverui from the Evolution-Data-Server module,
      since Evolution is its only consumer nowadays, and I'd like to make some
      improvements to those APIs without concern for backward-compatibility.
      And finally, start a Gtk-Doc module for libeutil.  It's going to be a
      project just getting all the symbols _listed_ much less _documented_.
      But the skeletal structure is in place and I'm off to a good start.
  21. 07 Dec, 2012 7 commits
    • Matthew Barnes's avatar
      Teach EMailExtensionRegistry to find extensions. · bf30024d
      Matthew Barnes authored
      Now we have the following extension points in the GType hierarchy:
      A registry just needs to be given one of these extension points, and it
      can use g_type_children() to find and load all registered extensions.
      This eliminates e-mail-format-extensions.[ch] as well as the dynamic
      loaders I added a few commits back.  Dynamically loaded extensions are
      now easier to register, at the cost of internal extensions being a tad
      more cumbersome to register.  Fair tradeoff, imo.
      This also makes e_mail_extension_registry_add_extension() a private
      function used only by e_mail_formatter_extension_registry_load() and
    • Matthew Barnes's avatar
      Add EMailFormatterQuoteExtension. · cbb7786a
      Matthew Barnes authored
      This is an abstract base type for formatter extensions which are
      intended only for use by EMailFormatterQuote.
    • Matthew Barnes's avatar
      EMailFormatterExtension: Convert get_description() to a string field. · d9699159
      Matthew Barnes authored
      Of the formatter extensions that provide a description, they all use a
      static string.  So we don't need an instance of the extension to obtain
      its description.  Just make it a string field in the class structure.
    • Matthew Barnes's avatar
      EMailFormatterExtension: Convert get_display_name() to a string field. · 7885426c
      Matthew Barnes authored
      Of the formatter extensions that provide a display name, they all use a
      static string.  So we don't need an instance of the extension to obtain
      its display name.  Just make it a string field in the class structure.
    • Matthew Barnes's avatar
      Convert EMailFormatterExtension to an abstract class. · 00b211b0
      Matthew Barnes authored
      With the previous changes, all formatter extensions derive from
      GObjectClass and implement the EMailFormatterExtensionInterface.
      Simplify things further by making EMailFormatterExtension an abstract
      base class so formatter extensions are now just direct subclasses and
      need not bother with implementing GObject interfaces.
    • Matthew Barnes's avatar
      Remove EMailExtension. · 54455ca1
      Matthew Barnes authored
      EMailExtension is now too trivial to keep as a standalone interface.
      Add a 'mime_types' string array to the EMailFormatterExtension and
      EMailFormatterParser interface structs.
      Alter e_mail_extension_registry_add_extension() to take a 'mime_types'
      string array and the GType of an extension to instantiate, rather than
      the extension instance directly.
      e_mail_extension_registry_remove_extension() is no longer needed.
    • Matthew Barnes's avatar
      EMailExtension: Replace mime_types() method with a string array. · 9d34f72e
      Matthew Barnes authored
      In all implementations for EMailExtension, the MIME type list is a
      static string array -- with the single exception of the text-highlight
      module, where the MIME type list is dynamically assembled once.
      Replace the mime_types() method with a "mime_types" string array in the
      EMailExtensionInterface struct.  Then the list of MIME types supported
      by the class implementing the EMailExtensionInterface can be obtained
      without requiring an instance of the class.
  22. 19 Aug, 2012 1 commit
  23. 13 Jul, 2012 1 commit
  24. 25 Jun, 2012 2 commits
  25. 06 Jun, 2012 1 commit
    • Dan Vrátil's avatar
      Mail formatter rewrite · 5b834056
      Dan Vrátil authored
      All mail-parsing and formatting code has been moved to em-format.
      Parsing is handeled by EMailParser class, formatting by EMailFormatter.
      Both classes have registry which hold extensions - simple classes
      that do actual parsing and formatting. Each supported mime-type
      has it's own parser and formatter extension class.