• Jehan's avatar
    plug-ins: various g_file_get_path() replaced by g_file_peek_path(). · 27dea4f7
    Jehan authored
    As explained in previous commits, the _peek_ call is advantageous
    - It is less bug-prone as we don't have to handle freeing the string. In
      all the cases I changed, I even spotted at least 2 cases where we were
      leaking a string (in file-mng, `temp_file_name` is never freed; and we
      were also leaking in an error case of gfig).
    - As a consequence of the previous point: simpler code with less lines.
    - In local file cases, the _peek_ variant does not even need to allocate
      an additional string.
    - In other case, if we query several times the path, it is allocated
      once and cached so it stays efficient.
    - When possible, working on the GFile rather than on a path string may
      be more robust. For instance I changed one g_unlink() into a
      g_file_delete(). Actually most reading/writing should be done with the
      GIO API when possible, but I didn't want to change too much code
      logics on this commit.