<table><tr><td style="">rkflx added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D12538">View Revision</a></tr></table><br /><div><div><p>After sleeping over this, I don't feel comfortable the way this is supposed to work for single click: Selection markers only really make sense when enabling multi-select mode. Abusing a single selection marker in single-select mode to mean "put the filename in the line edit so it is editable" feels really weird, and if you are doing this more often than overwriting (which might be very likely!) hitting the small icon is quite cumbersome.</p>

<p>IOW, I don't think the workaround which was promised to <a href="https://phabricator.kde.org/p/jtamate/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@jtamate</a>'s concern is good enough, and suggesting to switch to double click only to sustain a "pure" single click does not make sense to me either.</p>

<p>The question for single click is: What is the primary action which should be triggered immediately? Is it overwriting, or is it putting the filename in the field? For Dolphin and the <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Open</span></span></span> dialog it is clear that actually opening is the primary action. For <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Save</span></span></span> I'd argue that overwriting is only the secondary option, and thus should be triggered by the second click only.</p>

<p>I did some digging, and indeed this seems to be how it was originally implemented: <a href="https://phabricator.kde.org/R446:4ccd77256a0c8277e57d2a210bad321fba9c2e7f" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">4ccd77256a0c</a> added what this patch is now trying to remove again. Then right after that, <a href="https://phabricator.kde.org/R446:f729c291cdbb7154e431322d3b14516ee12610ea" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">f729c291cdbb</a> allowed double clicking to overwrite without moving the mouse to the <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Save</span></span></span> button. Somehow the latter commit got broken later on, I guess in <a href="https://phabricator.kde.org/R446:7f08f13809bc9bece921956dfd6fde20d1121246" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">7f08f13809bc</a> ("Hope I didn't miss anything." haha). Maybe that slot should have triggered only for <tt style="background: #ebebeb; font-size: 13px;">KFileWidget::Saving</tt>?</p>

<p>Given the concerns with selection markers in single-select mode and thus for <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Save</span></span></span> in general, and them being potentially far off in the future, can we think about changing this patch to double-click to overwrite, so single-click would still allow to append <tt style="background: #ebebeb; font-size: 13px;">_2</tt> to the filename, a likely more common operation? Users who set click behaviour to double click everywhere would not be affected by this change at all!</p>

<hr class="remarkup-hr" />

<p>Historical side note: In KDE3 with single click enabled, the first click would select in file dialogs, the second click would accept. In KDE4 accepting was refined to single click for <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Open</span></span></span>, but the double click was kept for <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Save</span></span></span>, which makes sense to me.</p>

<p>(And please think twice before making this discussion about a general single vs. double click debate again; I'm trying to improve single click to make more sense for the common use cases here, as we agreed upon as a sensible direction. Thanks ;)</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R241 KIO</div></div></div><br /><div><strong>BRANCH</strong><div><div>doubleclick_save (branched from master)</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D12538">https://phabricator.kde.org/D12538</a></div></div><br /><div><strong>To: </strong>anemeth, Frameworks, VDG, ngraham<br /><strong>Cc: </strong>rkflx, broulik, jtamate, ngraham, Frameworks, michaelh, bruns<br /></div>