1. 13 Sep, 2017 1 commit
  2. 21 Aug, 2017 1 commit
  3. 10 Aug, 2017 2 commits
  4. 08 Aug, 2017 4 commits
  5. 07 Aug, 2017 7 commits
  6. 06 Aug, 2017 3 commits
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · 0c9fdaad
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
      0c9fdaad
    • Friedrich W. H. Kossebau's avatar
    • Friedrich W. H. Kossebau's avatar
      [Feature] Enable per-project setting of source formatters · 47f298ae
      Friedrich W. H. Kossebau authored
      Summary:
      Patch adds a plugin kdevsourceformatter, as currently needed
      to provide some per-project config pages. To ensure it is
      always available, "X-KDevelop-LoadMode": "AlwaysOn" is set.
      This plugin then provides the per-project config page
      for source formatters.
      
      To reuse the code for selecting, editing, creating & deleting
      formatters, the respective code is factored out from
      the class KDevelop::SourceFormatterSettings
      into a new (exported) class KDevelop::SourceFormatterSelectionEdit,
      which is then used both from the global and the project config page.
      
      To enable the SourceFormarController instance to take the per-project
      settings into account, the API of ISourceFormatterController is
      changed to always include the url of the object, so the project
      it belongs to can be estimated.
      
      Test Plan:
      Changes to per-project settings are properly saved and restored in
      the UI.
      Source format controller takes settings of project into account
      if configured to do, both for snippets/line and whole files.
      
      Reviewers: #kdevelop, kfunk
      
      Reviewed By: #kdevelop, kfunk
      
      Subscribers: kfunk, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D6903
      47f298ae
  7. 05 Aug, 2017 1 commit
  8. 04 Aug, 2017 1 commit
  9. 02 Aug, 2017 2 commits
  10. 31 Jul, 2017 1 commit
  11. 30 Jul, 2017 2 commits
  12. 29 Jul, 2017 1 commit
  13. 27 Jul, 2017 2 commits
  14. 26 Jul, 2017 2 commits
  15. 21 Jul, 2017 2 commits
    • Friedrich W. H. Kossebau's avatar
      Use consistent icons & text for the "Close" actions · 546db738
      Friedrich W. H. Kossebau authored
      Summary:
      Consistently use "document-close" icon for close actions.
      
      Actions on view containers were talking about closing "Files",
      while actually they only closed the view (which would trigger
      closing of the document/file only if this was the last view).
      Talking just about "Close" without a target, like in the other
      actions, avoids trying to explain this concept, average user
      surely expects this, being a common pattern.
      
      Also moving the close actions in the document toolview context menu
      at the end, where close actions are usually placed.
      
      Reviewers: #kdevelop, kfunk
      
      Reviewed By: #kdevelop, kfunk
      
      Subscribers: kfunk, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D6819
      546db738
    • Friedrich W. H. Kossebau's avatar
      Proper lifetime support for one-time menu objects with contextMenuExtension · 1c7d1e65
      Friedrich W. H. Kossebau authored
      Summary:
      For actions and submenus created only for the given context for the menu,
      as opposed to persistent context-ignorant actions kept around all the time
      and owned by the plugin instance, in IPlugin::contextMenuExtension()
      overrides was no access to a QObject/QWidget element which could be used
      as QObject-style memory management for the given context menu event.
      So the old code for that either used instances like the plugin objects
      themselves or even none at all, which both de-facto results in
      accumulating lots of out-of-use QActions and QMenus during the runtime
      of KDevelop, only to be cleaned up either on destruction of the plugin
      instances at process end or never.
      
      Passing to IPlugin::contextMenuExtension a QWidget* object to be used
      as memory management parent matching the lifetime of the context menu
      allows to fix that.
      
      Test Plan:
      Invoked the context menus changed by the patch, and the temporarily
      added slots connected to QObject::destroyed handlers of the
      per-context-menu QAction & QMenu objects were invoked at the right time.
      No new crashes seen.
      
      Reviewers: #kdevelop, kfunk
      
      Reviewed By: #kdevelop, kfunk
      
      Subscribers: kfunk, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D6769
      1c7d1e65
  16. 18 Jul, 2017 2 commits
  17. 17 Jul, 2017 2 commits
  18. 16 Jul, 2017 1 commit
  19. 15 Jul, 2017 2 commits
  20. 14 Jul, 2017 1 commit