1. 19 Aug, 2019 1 commit
  2. 11 Aug, 2019 1 commit
  3. 02 Jul, 2019 1 commit
  4. 25 Jun, 2019 1 commit
  5. 22 Jun, 2019 1 commit
  6. 21 Jun, 2019 1 commit
  7. 20 Nov, 2018 2 commits
  8. 25 Oct, 2018 1 commit
  9. 22 Oct, 2018 2 commits
  10. 21 Oct, 2018 2 commits
  11. 01 Sep, 2018 1 commit
    • Friedrich W. H. Kossebau's avatar
      Sublime: on View destruction delete widget instantly, instead deleteLater · 8127e3fe
      Friedrich W. H. Kossebau authored
      Having a defined destruction order allows to make more assumptions
      in other code referring to the widgets and avoids extra work to track
      the addditional lifetime of the widget objects (like e.g. needed with
      the KTextEditor::View widget objects, which require the
      KTextEditor::MainWindow to exists as long as there is a View object).
      With the Sublime::View and the QWidget objects both bound to the same
      thread which is the UI objects thread by current design, there is also
      no need to defer the deletion into the QWidget object thread.
      Test Plan: Have been running this for more than a month, no issues seen.
      Reviewers: #kdevelop, kfunk
      Reviewed By: #kdevelop, kfunk
      Subscribers: kfunk, kdevelop-devel
      Tags: #kdevelop
      Differential Revision: https://phabricator.kde.org/D15198
  12. 17 Aug, 2018 1 commit
  13. 28 Jul, 2018 1 commit
    • Friedrich W. H. Kossebau's avatar
      Fix KTextEditor::MainWindow to outlive the KTextEditor::View objects · 1641d714
      Friedrich W. H. Kossebau authored
      The KTextEditor::MainWindow API requires that the MainWindow wrapper
      object passed to the created KTextEditor::View objects "stays valid
      for the complete lifetime of the view."
      The old code had Shell::MainWindow own the MainWindow wrapper
      object as child object, thus deleting as part of its own destruction.
      Though any KTextEditor::View objects still alive are being deleted
      with deleteLater(), so only destructed on the next QEvent::DeferredDelete
      handling. And they still assume they can access the MainWindow wrapper
      during their shutdown as normal, e.g. to call "MainWindow::deleteViewBar".
      To get things into some proper order again, this patch adds a method
      KTextEditorIntegration::MainWindow::startDestroy(), which now is called
      in the destruction of Shell::MainWindow instead of instantly deleting the
      MainWindow wrapper object as normal child object. The method starts a
      delayed delete instead, to outlive any TextEditor::View objects
      being deleteLatered() inside the Core::self()->shutdown().
      KTextEditorIntegration::MainWindow also gets fixed to know about the
      state of being destroyed and in that case no longer do things on the
      former mainwindow object.
      The patch also moves the layout code for stacking the viewbars into a
      new special class Sublime::ViewBarContainer. That solves lifetime and
      ownership handling of the widget and the layout, and hides the
      implementation detail behind a simple API.
      While this makes viewBarContainer() no longer a simple plain widget
      to be customized by any caller, no other user is known which would need
      Reviewers: #kdevelop, croick, mwolff
      Subscribers: kdevelop-devel
      Tags: #kdevelop
      Differential Revision: https://phabricator.kde.org/D13905
  14. 30 Nov, 2017 1 commit
    • Friedrich W. H. Kossebau's avatar
      Make SourceFormatter plugins enablable, hide actions with no plugins · a6a42ec3
      Friedrich W. H. Kossebau authored
      Source formatting is a feature seemingly only used by some.
      So it makes sense to allow disabling this feature, for some minimal smaller
      runtime footprint and less unused clutter in the UI (like menu actions or
      This patch achieves this to a good degree:
      * makes the plugins astyle & customscript normal global plugins which can be
        enabled/disabled by the user
      * removes the SourceFormatterController actions from the menus when there are
        no formatters available
      * shows no source formatting settings page in the project settings
        when there are no formatters available
      Not yet done is to hide the source formatting settings page from the
      application settings dialog in case no formatters are available. That might
      need some more custom logic all over the shell code, which is not so nice.
      Instead the option should be investigated to make the source formatting
      controller a normal plugin with a suited interface, which then can be
      queried by other code needing that service.
      Test Plan:
      See plugins astyle & customscript turn up in plugin selection settings.
      Disable and enable both and see how actions in the main Edit menu and the
      context menu on file items are present or not present, as well as the
      formatting settings page in the project settings dialog being shown or not.
      See also the formatting settings pages for projects and the global one only
      offering the formatters of the enabled plugins.
      Reviewers: #kdevelop, kfunk, mwolff
      Reviewed By: #kdevelop, kfunk, mwolff
      Subscribers: mwolff, kfunk, kdevelop-devel
      Differential Revision: https://phabricator.kde.org/D8492
  15. 16 Nov, 2017 1 commit
  16. 04 Nov, 2017 1 commit