1. 25 Şub, 2019 1 kayıt (commit)
  2. 13 Şub, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Remove dead and broken EmbeddedDatabases configuration · 74f9830d
      Stephan Bergmann yazdı
      As found out in 98c0b208 "Make Firebird the
      (unconditional) default for new databases":  "(Curiously,
      ODsnTypeCollection::getEmbeddedDatabase would read a DefaultEmbeddedDatabase
      value from the configuration before resorting to the hardcoded default, but
      `git log -SDefaultEmbeddedDatabase` makes it look like there has never been any
      code to actually write that setting.)"
      
      Digging deeper, the story appears to be as follows:  First, "INTEGRATION: CWS
      hsqldb" commits in 2004 had addded the EmbeddedDatabases group (and accompanying
      templates) to officecfg/registry/schema/org/openoffice/Office/DataAccess.xcs
      (ee11cb63), corresponding values (for HSQLDB)
      to officecfg/registry/data/org/openoffice/Office/DataAccess.xcu
      (60c5f0af), and code to read those values
      (lcl_getEmbeddedDatabase in dbaccess/source/ui/misc/dsntypes.cxx;
      ODsnTypeCollection::getEmbeddedDatabaseURL et al in
      dbaccess/source/ui/misc/dsntypes.cxx; all
      a68938bc).  This looks like it actually worked.
      
      Then, "INTEGRATION: CWS dba24b" commits in 2007 removed the EmbeddedDatabases
      configuration data from
      officecfg/registry/data/org/openoffice/Office/DataAccess.xcu
      (473a3ccf, "during #i80930#: The approach to
      read the concrete type of the embedded DB from the configuration does not work,
      there are enough places where we silently assume 'embedded == embedded HSQLDB'")
      and removed the code reading it (79bbd382), but
      left the EmbeddedDatabases schema data in
      officecfg/registry/schema/org/openoffice/Office/DataAccess.xcs untouched.
      
      Then, b88a62cc "CWS-TOOLING: integrate CWS
      dbaperf2" in 2009 reintroduced code that attempts to read the configuration data
      as ODsnTypeCollection::getEmbeddedDatabase
      (dbaccess/source/core/misc/dsntypes.cxx).  The reason for that may be
      "2009-05-06 14:22:21 +0200 oj  r271589 : #i101587# use config for the drivers"
      as listed in the commit message.  The code added as
      ODsnTypeCollection::getEmbeddedDatabase back then remained effectively unchanged
      until today, but looks fundamentally broken:  It starts out with trying to read
      an /org.openoffice.Office.DataAccess/EmbeddedDatabases/DefaultEmbeddedDatabase/
      Value property that can never be present per the schema (an
      /org.openoffice.Office.DataAccess/EmbeddedDatabases/DefaultEmbeddedDatabase
      property could be); so no data is ever actually read from the configuration by
      ODsnTypeCollection::getEmbeddedDatabase.  (And the commit also didn't add back
      any configuration data to
      officecfg/registry/data/org/openoffice/Office/DataAccess.xcu that could have
      been read in the first place, nor any code to generate such data
      programmatically.)
      
      So remove the broken code to read configuration data from
      ODsnTypeCollection::getEmbeddedDatabase (which means it can be a static member
      function now) and also remove the obviously unused EmbeddedDatabases group (and
      accompanying templates) from
      officecfg/registry/schema/org/openoffice/Office/DataAccess.xcs.
      
      Change-Id: Icc9b34075b9b7e960df6c236d3595b7fabe71f9d
      Reviewed-on: https://gerrit.libreoffice.org/67494
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      74f9830d
  3. 04 Kas, 2018 2 kayıt (commit)
  4. 11 May, 2018 1 kayıt (commit)
  5. 03 Ock, 2018 1 kayıt (commit)
  6. 14 Ara, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      No need to keep these whitelisted functions decorated with SAL_CALL · 6f4f5677
      Stephan Bergmann yazdı
      The only effect SAL_CALL effectively has on LO-internal code is to change non-
      static member functions from __thiscall to __cdecl in MSVC (where all other
      functions are __cdecl by default, anyway).  (For 3rd-party code, it could be
      argued that SAL_CALL is useful on function declarations in the URE stable
      interface other than non-static member functions, too, in case 3rd-party code
      uses a compiler switch to change the default calling convention to something
      other than __cdecl.  But loplugin:salcall exempts the URE stable interface,
      anyway.)
      
      One could argue that SAL_CALL, even if today it effectively only affects non-
      static member functions in MSVC, could be extended in the future to affect more
      functions on more platforms.  However, the current code would already not
      support that.  For example, 3af50058
      "loplugin:salcall fix functions" changed FrameControl_createInstance in
      UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
      though its address (in ctl_component_getFacrory, in the same file) is passed to
      cppuhelper::createSingleFactory as an argument of type
      cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
      
      Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
      Reviewed-on: https://gerrit.libreoffice.org/46436Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      6f4f5677
  7. 11 Ara, 2017 1 kayıt (commit)
  8. 05 Ara, 2017 1 kayıt (commit)
  9. 06 Kas, 2017 1 kayıt (commit)
  10. 23 Eki, 2017 1 kayıt (commit)
  11. 24 Tem, 2017 1 kayıt (commit)
  12. 21 Tem, 2017 1 kayıt (commit)
    • Caolán McNamara's avatar
      migrate to boost::gettext · 00657aef
      Caolán McNamara yazdı
      * all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
      * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
      * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
        MODULE .mo files
      * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
        goes from l10n target to normal one, so the res/lang.zips of UI files go away
      * translation via Translation::get(hrc-define-key, imbued-std::locale)
      * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
        to keep finding the .hrc file uniform) so magic numbers can go away there
      * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
        mechanism
      * en-US res files go away, their strings are now the .hrc keys in the source code
      * remaining .res files are replaced by .mo files
      * in .res/.ui-lang-zip files, the old scheme missing translations of strings
        results in inserting the english original so something can be found, now the
        standard fallback of using the english original from the source key is used, so
        partial translations shrink dramatically in size
      * extract .hrc strings with hrcex which backs onto
         xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
      * extract .ui strings with uiex which backs onto
         xgettext --add-comments --no-wrap
      * qtz for gettext translations is generated at runtime as ascii-ified crc32 of
         content + "|" + msgid
      * [API CHANGE] remove deprecated binary .res resouce loader related uno apis
            com::sun::star::resource::OfficeResourceLoader
            com::sun::star::resource::XResourceBundleLoader
            com::sun::star::resource::XResourceBundle
          when translating strings via uno apis
            com.sun.star.resource.StringResourceWithLocation
          can continue to be used
      
      Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
      00657aef
  13. 18 Tem, 2017 1 kayıt (commit)
  14. 13 Tem, 2017 1 kayıt (commit)
  15. 03 Mar, 2017 1 kayıt (commit)
  16. 17 Şub, 2017 1 kayıt (commit)
  17. 26 Ock, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Remove dynamic exception specifications · e57ca028
      Stephan Bergmann yazdı
      ...(for now, from LIBO_INTERNAL_CODE only).  See the mail thread starting at
      <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
      "Dynamic Exception Specifications" for details.
      
      Most changes have been done automatically by the rewriting loplugin:dynexcspec
      (after enabling the rewriting mode, to be committed shortly).  The way it only
      removes exception specs from declarations if it also sees a definition, it
      identified some dead declarations-w/o-definitions (that have been removed
      manually) and some cases where a definition appeared in multiple include files
      (which have also been cleaned up manually).  There's also been cases of macro
      paramters (that were used to abstract over exception specs) that have become
      unused now (and been removed).
      
      Furthermore, some code needed to be cleaned up manually
      (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
      configurations available that would actually build that code.  Missing @throws
      documentation has not been applied in such manual clean-up.
      
      Change-Id: I3408691256c9b0c12bc5332de976743626e13960
      Reviewed-on: https://gerrit.libreoffice.org/33574Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      e57ca028
  18. 19 Ock, 2017 1 kayıt (commit)
  19. 13 Eyl, 2016 1 kayıt (commit)
    • Stephan Bergmann's avatar
      loplugin:override: No more need for the "MSVC dtor override" workaround · 91dd2db1
      Stephan Bergmann yazdı
      The issue of 362d4f0c "Explicitly mark
      overriding destructors as 'virtual'" appears to no longer be a problem with
      MSVC 2013.
      
      (The little change in the rewriting code of compilerplugins/clang/override.cxx
      was necessary to prevent an endless loop when adding "override" to
      
        OOO_DLLPUBLIC_CHARTTOOLS    virtual ~CloseableLifeTimeManager();
      
      in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
      OOO_DLLPUBLIC_CHARTTOOLS macro.  Can't remember what that
      isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
      
      Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
      91dd2db1
  20. 05 Agu, 2016 1 kayıt (commit)
  21. 15 Tem, 2016 1 kayıt (commit)
  22. 20 Nis, 2016 1 kayıt (commit)
  23. 13 Nis, 2016 1 kayıt (commit)
  24. 12 Nis, 2016 3 kayıt (commit)
  25. 14 Mar, 2016 1 kayıt (commit)
  26. 08 Şub, 2016 1 kayıt (commit)
  27. 29 Ock, 2016 1 kayıt (commit)
    • akki95's avatar
      whitespace fixup · 82b4afb4
      akki95 yazdı
      Change-Id: Ia5a2cd92e069c038f4ff0c97876b95c5d81e4db1
      82b4afb4
  28. 11 Ock, 2016 1 kayıt (commit)
  29. 12 Ara, 2015 1 kayıt (commit)
  30. 16 Kas, 2015 1 kayıt (commit)
  31. 10 Kas, 2015 1 kayıt (commit)
  32. 12 Eki, 2015 2 kayıt (commit)
  33. 03 Agu, 2015 2 kayıt (commit)
  34. 27 Tem, 2015 2 kayıt (commit)