1. 04 Oct, 2020 1 commit
  2. 03 Oct, 2020 1 commit
  3. 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
  4. 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).
  5. 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
  6. 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
  7. 25 Sep, 2020 3 commits
  8. 17 Sep, 2020 2 commits
  9. 15 Sep, 2020 1 commit
  10. 13 Sep, 2020 2 commits
  11. 12 Sep, 2020 1 commit
  12. 10 Sep, 2020 4 commits
  13. 06 Sep, 2020 1 commit
  14. 31 Aug, 2020 1 commit
  15. 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
  16. 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
  17. 17 Aug, 2020 1 commit
  18. 15 Aug, 2020 1 commit
  19. 10 Aug, 2020 2 commits
  20. 08 Aug, 2020 1 commit
  21. 01 Aug, 2020 2 commits
  22. 13 Jul, 2020 1 commit
  23. 12 Jul, 2020 1 commit
  24. 11 Jul, 2020 1 commit
  25. 04 Jul, 2020 1 commit
  26. 01 Jul, 2020 1 commit
  27. 25 Jun, 2020 1 commit
  28. 23 Jun, 2020 2 commits
  29. 19 Jun, 2020 1 commit
    • Nate Graham's avatar
      Move "Switch Application Language" to Settings menu · a957f121
      Nate Graham authored
      This is where it logically belongs. Applications with only a Help menu
      and no settings menu will still get it displayed in there due to some
      fancy code in khelpmenu.cpp, so there are no cases where the menu item
      will become completely inaccessible.
      Test Plan:
      1. Open Okular, Konsole, or Dolphin with its menu bar shown
      2. Look in Settings and Help menus to make sure the action is in the
         Settings menu
      1. Open an app without a visible Settings menu such as Spectacle or
         Dolphin with its menubar hidden
      2. Look in the help menu to make sure the action is shown there
      BUG: 177856
      FIXED-IN: 5.72