[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Breadcrumbs in Kickoff
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2011-12-21 20:33:52
Message-ID: CAPLgePougbptRDuS_6TcbtT3LztyBDiypG5eV3QnXFw1Y=S4Ww () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Dec 21, 2011 at 21:07, Alexey Chernov <4ernov@gmail.com> wrote:
> On 20 =D0=B4=D0=B5=D0=BA 2011 19:31:06 Rick Stockton wrote:
> > Alexey, you have two of KDE's smartest people (Aaron and Martin) in
> > agreement that we probably want to provide this via the "Back" Button o=
n
> > the Mouse. (Less new code, less confusion, less maintenance headache.)
> > That's the option on the table, with tentative "+1" assessments. Would
> > that alternative be INADEQUATE, in a REALLY IMPORTANT way?
> >
> > If it's got a defect, I really don't see it. Please advise.
>
> No, nothing against except that mouse buttons can be easily rearranged (f=
or
> instance, I have 'back' and 'forward' buttons on my mouse but arranged
> them as
> 'copy' and 'paste'). Anyway it's definitely better to have it if it's eas=
y
> to
> implement as you describe, so thank you for a good idea.
>
> In my opinion, the main discussion here is around GUI elements and this
> approach is quite similar to hotkeys, it's a little bit different story.
>
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?
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.
--
Martin Klapetek | KDE Developer
[Attachment #5 (text/html)]
<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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic