<div class="gmail_quote">On Wed, Dec 21, 2011 at 21:07, Alexey Chernov <span dir="ltr"><<a href="mailto:4ernov@gmail.com">4ernov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 20 дек 2011 19:31:06 Rick Stockton wrote:<br>
> Alexey, you have two of KDE's smartest people (Aaron and Martin) in<br>
> agreement that we probably want to provide this via the "Back" Button on<br>
> the Mouse. (Less new code, less confusion, less maintenance headache.)<br>
> That's the option on the table, with tentative "+1" assessments. Would<br>
> that alternative be INADEQUATE, in a REALLY IMPORTANT way?<br>
><br>
> If it's got a defect, I really don't see it. Please advise.<br>
<br>
</div>No, nothing against except that mouse buttons can be easily rearranged (for<br>
instance, I have 'back' and 'forward' buttons on my mouse but arranged them as<br>
'copy' and 'paste'). Anyway it's definitely better to have it if it's easy to<br>
implement as you describe, so thank you for a good idea.<br>
<br>
In my opinion, the main discussion here is around GUI elements and this<br>
approach is quite similar to hotkeys, it's a little bit different story.<br></blockquote><div><br>To play the devil's advocate here - as the main reason against bringing it back is mostly the increased code complexity, then if you add whole support for additional mouse buttons that actually trigger the back action, isn't the back button then just like 10 lines of qml code? Ie. just hook the onClick: to the "one-level-back" action?<br>

<br clear="all"><div>But then again - I don't really care that much about that button as I use mostly KRunner and I respect the decision. Should there be a vote though, I'd probably vote in favor of it.<br><br></div>

--<div><font color="#666666">Martin Klapetek | KDE Developer</font></div></div></div>