1. 02 Oct, 2020 1 commit
    • Nate Graham's avatar
      [kmainwindow] Don't delete entries from an invalid kconfiggroup · f431b93e
      Nate Graham authored
      If for some reason the config group we're trying to delete entries from
      doesn't exist, the app will assert in KConfigGroup::deleteEntry in
      `Q_ASSERT_X(isValid(), "KConfigGroup::deleteEntry", "accessing an
      invalid group");`
      So let's guard against that by only deleting the entry from the config
      group if the group itself is valid. Maybe it's not, for some reason.
      BUG: 427236
      FIXED-IN: 5.75
  2. 01 Oct, 2020 2 commits
    • Nate Graham's avatar
      Don't overlap main windows when opening additional instances · ab43b986
      Nate Graham authored
      Right now when restoring the position of main windows, we do it
      unconditionally. This means that if you have a KXMLGui-using app
      open and you open a new instance, the new instance gets position-
      restored and totally overlaps the existing window. This is not
      very nice.
      With this commit, that issue is fixed.
      Technical explanation: To accomplish this, now every time the
      window position data is read, we write out a value to the config
      file that indicates that we should not restore the position of the
      next window to be opened. This ensures that after opening one
      instance, the next one will never cover it up completely. Whenever
      any window is closed, we clear the config file value so that the
      next-opened window can once again restore the position of the last-
      opened one.
      This is functionally equivalent to clearing the position config
      data on disk after reading it, but is simpler and does not result
      in that data being lost if the app crashes (in which case the main
      window wouldn't get closed nicely to write the data out again).
      UX explanation: Apps where you regularly open multiple instances will
      no longer overlap one another, and the last-closed instance will be
      the one which gets its position saved. When you re-open that app
      after closing all instances, it will remember the last position of
      that window, but opening additional instances will let the window
      manager position them according to its own window placement settings.
      BUG: 426725
      FIXED-IN: 5.75
    • Nate Graham's avatar
      Fix KMainWindow::canBeRestored to return false in the right times · 3e72053a
      Nate Graham authored
      Right now if there is a session config but it has no data in it,
      `KMainWindow::canBeRestored()` will return true if you call it with the
      number 1 as an argument. This is because it will try to read the
      NumberOfWindows key, see that it does not exist, and fall back to the
      number 1 as the default value, which will be identical to the number you
      called the function with.
      Instead let's set the default value to 0, which will fix this and also
      be more accurate too (there really are zero windows saved).
  3. 30 Sep, 2020 1 commit
    • David Edmundson's avatar
      Fix test that KMainWindow is a toplevel window · c0407a38
      David Edmundson authored
      We want to test if there is a parent window and only run some code if we
      are a valid toplevel.
      !window() covers the case before our window is shown, but after showing
      our window() will return ourself as the object when there is no parent.
      Fixes 03b0f4c3
      Relevant unit tests now pass
  4. 29 Sep, 2020 1 commit
    • David Edmundson's avatar
      [kmainwindow] Don't create native windows for non-toplevel windows · 03b0f4c3
      David Edmundson authored
      winId() creates a QPlaformWindow; i.e a native xcb_window or wl_surface.
      This makes sense for a toplevel which will be a real window.
      If someone (in this case localize) uses kmainwindow as a subwidget
      inside an existing window the current code will create a subwindow for
      this widget. It's a very weird window, as the window is never actually
      mapped so all contents are drawn as part of the parent window. Leaving
      us in a very corrupt state.
      Doing this on XCB is wasteful but the side effects are unnoticed. On
      QtWayland things explode in weird ways.
      BUG: 424024
  5. 25 Sep, 2020 1 commit
  6. 17 Sep, 2020 1 commit
  7. 15 Sep, 2020 1 commit
  8. 10 Sep, 2020 1 commit
  9. 28 Aug, 2020 1 commit
    • Nate Graham's avatar
      Allow opting out of remembering window positions on X11 · 39f7171d
      Nate Graham authored
      Various people have requested this, for reasons that seem sensible
      enough to me:
      - Some people like the KWin positioning modes and want all windows to
        follow them
      - It might be annoying to have only KDE apps follow this setting and
        preferable to not use it at all for pepole who use mostly non-KDE apps
      - The per-screen-arrangement memory feature may interact strangely or in
        a buggy manner for some people's screen arrangements
      For those reasons, it seems reasonable to allow disabling the feature,
      though it still remains on by default. This commit turns it off if
      `AllowKDEAppsToRememberWindowPositions=false` is set in the user's
      `kdeglobals` file. A GUI to toggle this will be added in a separate
      commit to some System Settings KCM.
      CCBUG: 415150
  10. 20 Aug, 2020 1 commit
    • Nate Graham's avatar
      Save and restore position of main window · bbcfcc53
      Nate Graham authored
      This commit invokes the new KWindowConfig::saveWindowPosition() and
      KWindowConfig::restoreWindowPosition() added to KConfig in
      frameworks/kconfig!14. As a
      result, KDE apps using KXMLGui now automatically save and restore the
      positions of their windows on a per-screen-arrangement basis.
      BUG: 415150
      FIXED-IN: 5.74
  11. 10 Aug, 2020 2 commits
  12. 04 Jun, 2020 1 commit
    • Igor Poboiko's avatar
      [KMainWindow] Invoke QIcon::setFallbackThemeName (later) · 899c0f7f
      Igor Poboiko authored
      This is alternative approach to {D22488} and commit 4214045 to KIconThemes.
      Okular (and most - if not all - KDE apps) inherit KMainWindow, so KDE apps
      should have breeze icons). KMainWindow ctor should be early enough so no icons
      are yet loaded, but late enough so QGuiApplication is already inited.
      This should be followed by reverting commit 4214045 in KIconThemes.
      Original problem description (by @mart):
      invoking QIcon::setFallbackThemeName at QCoreApplication ctor
      with Q_COREAPP_STARTUP_FUNCTION breaks the internal status of
      QIconLoader as it instantiates it before the QPlatformTheme,
      but QIconLoader depends from QPlatformTheme to be already instantiated
      otherwise it won't load correctly, thus breaking icon loading
      in QtQuickControls2 styles, such as Material and Fusion
      see https://bugreports.qt.io/browse/QTBUG-74252
      CCBUG: 402172
      Test Plan:
      Don't have GTK3 QPA plugin, so cannot test it yet.
      I would appreciate if someone helped me with testing :)
      Reviewers: aacid, mart, broulik
      Subscribers: mart, kde-frameworks-devel
      Tags: #frameworks
      Differential Revision: https://phabricator.kde.org/D29826
  13. 11 Jan, 2020 1 commit
    • Friedrich W. H. Kossebau's avatar
      KMainWindow: fix autoSaveSettings to catch QDockWidgets being shown again · 6f08f7ae
      Friedrich W. H. Kossebau authored
      If QDockWidgets are "shown" in QWidget sense a second time, no resize or
      move events might happen as the widget has already been layouted before
      and might simply reappear at same position with same size.
      The old logic did not catch this, so would keep an outdated state stored
      in the auto-save settings of the window, which then would result in wrong
      state being enforced on restoring.
      Test Plan:
      Open KDevelop, open a toolview which was not open before (e.g. "Search in
      all Files"), switch to another toolview not open before, then switch back
      to the first toolview. Now either switch the currently viewed document
      (e.g. open another file) or quit & reopen KDevelop.
      Before the first toolview would hide itself despite officially being still
      visible, with this patch the state is properly hold (when internally being
      restored, like during finalizeGUI on KXmlGui client change).
      Reviewers: #frameworks, #kdevelop, dfaure
      Reviewed By: dfaure
      Subscribers: SGOrava, kde-frameworks-devel
      Tags: #frameworks
      Differential Revision: https://phabricator.kde.org/D26501
  14. 08 Jan, 2020 1 commit
    • David Edmundson's avatar
      Drop unused headers · 0c410c8e
      David Edmundson authored
      KWindowSystem as a framework is still used or KKeyServer, so it can't be
      completely removed.
      Test Plan: Compiles
      Reviewers: apol
      Reviewed By: apol
      Subscribers: kde-frameworks-devel
      Tags: #frameworks
      Differential Revision: https://phabricator.kde.org/D26512
  15. 01 Dec, 2019 1 commit
  16. 20 Nov, 2019 1 commit
    • Nate Graham's avatar
      Also allow invoking session restoration logic when apps are manually launched · 46e5b32e
      Nate Graham authored
      Right now session restoration logic only ever gets invoked when apps are started
      automatically after rebooting, because of the check for `qApp->isSessionRestored()`.
      This limits the feature to only working for that use case, since `qApp->isSessionRestored()`
      is set by Qt and we can't override it in the app itself to signal that we want the session
      restoration behavior for other reasons. As a result, we can't use it to implement the
      behavior of restoring the condition of app when it's manually launched, which has been
      requested for several of our apps.
      This patch removes the check for `qApp->isSessionRestored()`, which opens the door to
      implementing the requested features in our apps.
      CCBUG: 397463
      CCBUG: 413564
      Test Plan:
      D11382 now works
      Normal session restoration behavior after a reboot is unchanged
      Apps with session restoration behavior but without a user-facing option to invoke it
      don't restore session at inappropriate times.
      Reviewers: davidedmundson, #frameworks
      Reviewed By: davidedmundson
      Subscribers: kde-frameworks-devel
      Tags: #frameworks
      Differential Revision: https://phabricator.kde.org/D25106
  17. 20 Oct, 2019 1 commit
  18. 17 Oct, 2019 1 commit
    • Friedrich W. H. Kossebau's avatar
      Use ECMGenerateExportHeader to manage deprecated API better · 808bd05b
      Friedrich W. H. Kossebau authored
      * projects linking to KXmlGui to hide deprecated API up to a
        given version or silence deprecation warnings after a given version,
      * to build KXmlGui optionally with deprecated API excluded from
        the build, using "EXCLUDE_DEPRECATED_BEFORE_AND_AT" cmake argument.
      Test Plan:
      Builds with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to 0, 4.1.0, 5.0.0,
      Reviewers: #frameworks, dfaure, mlaurent
      Reviewed By: dfaure, mlaurent
      Subscribers: kde-frameworks-devel
      Tags: #frameworks
      Differential Revision: https://phabricator.kde.org/D24466
  19. 10 Sep, 2019 1 commit
  20. 09 Sep, 2019 1 commit
  21. 24 Aug, 2019 1 commit
  22. 19 Jul, 2019 1 commit
    • Kai Uwe Broulik's avatar
      Remove visibilityChanged connection in favor of existing eventFilter · d4af86d8
      Kai Uwe Broulik authored
      KMainWindow compresses saving its configuration by a 500ms timer. However, for QDockWidget visibilityChanged
      a direct connection to the setSettingsDirty method is made, which immediately saves settings.
      Since there is already an eventFilter also listening for QEvent::Show and QEvent::Hide, the connection to
      visibilityChanged is redundant since that signal is emitted from the respective event handler anyway.
      The main benefit is that the eventFilter code compresses the configuration save,
      not jeopardizing startup time for applications with lots of dock widgets like Dolphin.
      Differential Revision: https://phabricator.kde.org/D22523
  23. 18 Jul, 2019 1 commit
  24. 25 Jan, 2019 1 commit
  25. 04 Nov, 2018 1 commit
  26. 23 Oct, 2018 1 commit
  27. 22 Oct, 2018 1 commit
  28. 17 Jul, 2018 1 commit
    • Mladen Milinkovic's avatar
      Fix KMainWindow saving incorrect widget settings · d35a8828
      Mladen Milinkovic authored
      BUG: 395988
      In certain cases KMainWindow::saveMainWindowSettings() could have been
      called after mainwindow started destroying itself. Window settings would
      be saved with incorrect child widget states. e.g. some widgets would be
      saved as hidden even if they were visible before destroying.
  29. 04 May, 2018 1 commit
  30. 13 Apr, 2018 1 commit
  31. 11 Mar, 2018 1 commit
  32. 16 Aug, 2017 1 commit
  33. 16 Jan, 2017 2 commits
  34. 20 Dec, 2016 1 commit
  35. 20 Oct, 2016 1 commit
  36. 13 Mar, 2016 2 commits