Save config when opening the config dialog
ClosedPublic

Authored by huoni on Feb 18 2018, 9:21 AM.

Details

Summary

Some settings can be changed outside of the config dialog. We don't
want these changes to be lost when changing the config, which
triggers reloading of the config.

BUG: 390331

Test Plan

Settings changed outside the config dialog, e.g. thumbnail zoom level in Browse view,
should not reset if you change a setting in the config dialog.

Diff Detail

Repository
R260 Gwenview
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
huoni requested review of this revision.Feb 18 2018, 9:21 AM
huoni created this revision.
huoni added a reviewer: rkflx.Feb 18 2018, 9:21 AM
rkflx accepted this revision.EditedFeb 18 2018, 9:34 AM

Compared to the verbose bug report, the fix seems so simple – Awesome!

Just a small niggle, then this can land.

app/mainwindow.cpp
1445–1446

Please move this to the very top, and add a linebreak below.

This revision is now accepted and ready to land.Feb 18 2018, 9:34 AM
huoni updated this revision to Diff 27451.Feb 18 2018, 9:37 AM
  • Improve code readability
huoni added a comment.Feb 18 2018, 9:37 AM

Compared to the verbose bug report, the fix seems so simple – Awesome!

I was pleasantly surprised myself!

Just a small niggle, then this can land.

Done

This revision was automatically updated to reflect the committed changes.
rkflx added a comment.Feb 18 2018, 9:58 PM

Oh no, I committed this to the wrong branch, now I have to cherry-pick to stable. Normally merging from stable to master is preferred.

@huoni In case of bugfixes (no changes of user-visible strings, no new features, no change in behaviour, low risk etc.) you can do this:

git checkout Applications/17.12
arc feature a-new-feature

This will create a new branch based on the stable branch and set the stable branch as the upstream tracking branch, which will be visible via gitk --all as well as in Phabricator ("branched from").

This helps communicating to the reviewer/committer where a patch should go. Anyway, in the end it was my mistake. Oops!

Oh no, I committed this to the wrong branch, now I have to cherry-pick to stable. Normally merging from stable to master is preferred.

@huoni In case of bugfixes (no changes of user-visible strings, no new features, no change in behaviour, low risk etc.) you can do this:

git checkout Applications/17.12
arc feature a-new-feature

This will create a new branch based on the stable branch and set the stable branch as the upstream tracking branch, which will be visible via gitk --all as well as in Phabricator ("branched from").

This helps communicating to the reviewer/committer where a patch should go. Anyway, in the end it was my mistake. Oops!

I'll try to remember that!

Is this pattern consistent across KDE? I.e. master and stable?

rkflx added a comment.EditedFeb 18 2018, 10:43 PM

Is this pattern consistent across KDE? I.e. master and stable?

Well, it depends ;) In general, most repositories prefer a merging strategy instead of cherry-picking (see Git history or ask for exceptions). In terms of branches, for KDE's main "products" you'll see:

  • KDE Frameworks: only a master branch (but releases on a monthly cadence instead)
  • KDE Plasma: master and stable branches (e.g. Plasma/5.12 at the moment)
  • KDE Applications: master and stable branches (e.g. Applications/17.12, soon Applications/18.04)

See https://community.kde.org/Schedules for further insights.