1. 30 Sep, 2018 2 commits
  2. 30 Aug, 2018 1 commit
  3. 29 Aug, 2018 1 commit
  4. 11 Aug, 2018 2 commits
    • Sam Thursfield's avatar
      Allow use of domain rules that aren't installed into /usr · 5a58a451
      Sam Thursfield authored
      Currently Tracker domain rules must be installed inside Tracker's data
      directory (usually /usr/share/tracker). This is limiting as it means
      only system packages can add them. A program installed into /opt is
      unable to use a custom domain, for example. Since Tracker is implemented
      as a system of daemons, it's not particularly straight forward to work
      around this by setting XDG_DATA_DIRS= to point somewhere non-standard
      either.
      
      This patch removes this restriction in a simple way: it allows users to
      pass a full path to the domain rule, rather than just the base name.
      5a58a451
    • Sam Thursfield's avatar
      tracker_domain_ontology_get_domain() should return only the domain name · d7076fff
      Sam Thursfield authored
      We should be consistent about what the name of a Tracker domain actually
      is. In the domain rule we specify Domain=org.freedesktop (for the
      default rule) or Domain=org.example.App (for a custom domain). But
      internally tracker_domain_ontology_get_domain() would return
      org.freedesktop.Tracker1 or org.example.App.Tracker1, i.e. the domain
      name now has '.Tracker1' appended.
      
      This does make sense in most cases, but it means there's no way to get
      the actual name of the domain from a TrackerDomainOntology object. This
      commit changes the existing function to not append '.Tracker1' in the
      value it returns, which means that function can now be used to get the
      base name of the domain. The assumption is that callers are normally
      appending stuff to this base name anyway so it's not much extra effect
      to also append the '.Tracker1' component if needed.
      
      libtracker-common is internal to Tracker so this doesn't constitute a
      public API break.
      d7076fff
  5. 16 Jul, 2018 2 commits
  6. 01 Jul, 2018 1 commit
  7. 22 Jun, 2018 1 commit
    • Carlos Garnacho's avatar
      tracker-extract: Delegate activation on tracker-miner-fs · 0f3e7ee6
      Carlos Garnacho authored
      This process is safe to shutdown on inactivity, so let's just do
      that. tracker-miner-fs was already partially in charge of
      tracker-extract's lifetime through its watchdog. With this commit
      it is now totally in charge of it, autostarting it whenever there's
      any content that hasn't gone yet through it.
      
      In order to keep recovering from crashes from tracker extract,
      perform the check whenever the DBus name is lost, it'll be a no-op
      if tracker-extract is legitimately shutting down due to inactivity.
      0f3e7ee6
  8. 16 Dec, 2017 1 commit
    • Sam Thursfield's avatar
      Rename libtracker-common to libtracker-miners-common · 3cee7b92
      Sam Thursfield authored
      We made a big compromise when splitting tracker core from tracker-miners
      in that the common code that was needed by both parts would end up
      duplicated. It's ugly but it works fine at the moment and allows us to
      keep all of the common code private.
      
      I had an issue when trying to embed tracker core into tracker-miners as
      a Meson subproject though. Having two targets named tracker-common
      caused confusion as duplicate targets aren't allowed, but they are not
      quite equivalent so we can't just pick one or the other.
      
      To work around this, I've renamed the copy in this repo to
      tracker-miners-common. This only affects the target names, not the
      actual function names.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=789725
      3cee7b92
  9. 10 Aug, 2017 1 commit
  10. 03 Aug, 2017 1 commit
    • Carlos Garnacho's avatar
      Remove code not related to miners · 63af0cfe
      Carlos Garnacho authored
      The miners are being split from the core tracker package.
      
      On both autotools/meson builds, datadir and libdir for
      private data has been changed to be separate from the tracker
      core. Same goes for the gettext package and other bits.
      
      Additionally, avoid installing the dbus xml descriptions.
      That's fairly non-standard and unnecessary with introspection.
      63af0cfe
  11. 06 Jul, 2017 1 commit
  12. 29 Jun, 2017 6 commits
  13. 30 Jan, 2017 1 commit
  14. 09 Oct, 2016 1 commit
  15. 14 Jul, 2016 1 commit
    • Sam Thursfield's avatar
      Use TrackerResource instead of TrackerSparqlBuilder in all extractors · 8cc026da
      Sam Thursfield authored
      For a long time, all the Tracker extractors have manually constructed a
      SPARQL update command using TrackerSparqlBuilder to represent their
      output. This commit changes all of them to use the TrackerResource
      class instead, which makes the code a lot more concise and readable.
      
      This introduces some API breaks in the internal libtracker-extract
      library. This has been a private library since Tracker 0.16 or earlier,
      so it's fine.
      
      If the extractors only output SPARQL then they are only useful to
      people who are using a SPARQL store. Now we can output a serialization
      format like Turtle as well. This will hopefully make the extract modules
      useful outside of Tracker itself.
      
      I've tried to preserve the behaviour of the extractors as much as
      possible, but there are two things that are now handled differently:
      
        * nao:Tag resources are given a fixed URI based on the tag label, such
          as <urn:tag:My_Tag>. Previously they were inserted as blank nodes,
          so tracker-store would give them unique IDs like <urn:uuid:1234...>
      
        * All extractors created nco:Contact resources for content publishers,
          but previously some would assign fixed URIs based on the name
          <urn:contact:James%20Joyce>, while others would insert them as blank
          nodes so they would be assigned unique IDs like <urn:uuid:1234...>.
          Now, all extractors create nco:Contact resources with fixed URIs
          based on the content creator's name.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=767472
      8cc026da
  16. 07 May, 2016 1 commit
  17. 27 Dec, 2014 1 commit
  18. 27 Oct, 2014 1 commit
  19. 01 Aug, 2014 2 commits
  20. 28 Jul, 2014 1 commit
  21. 18 Mar, 2014 2 commits
  22. 20 Feb, 2014 1 commit
  23. 06 Feb, 2014 1 commit
    • Martyn Russell's avatar
      build: depend on libmediaart · 356b2700
      Martyn Russell authored
      Previously we did everything ourselves, but now we've exported all mediaart
      functionality to a new library and we just link with that now!
      356b2700
  24. 21 Jan, 2014 3 commits
  25. 08 Mar, 2013 2 commits
  26. 14 Dec, 2011 1 commit
  27. 26 Sep, 2011 1 commit