Re: Re: Breadcrumbs in Kickoff, IMPORTANT FIXUP

2012-03-19 Thread Mark 
On Mon, Mar 19, 2012 at 8:15 AM, Rick Stockton <
rickstock...@reno-computerhelp.com> wrote:

>  I'll top post this one:
>
> OOPS! And PLEASE ignore my post, in Vol 45/Issue 46, where I talked about
> this being requiring "just an easy change": This requires no changes at
> all. It's already supported, and it even works back in 4.7.4. (Maybe
> earlier, but 4.7.4 is the earliest Release I have "lying around" for test
> purposes.)
>
> You only need to ignore the Doco Comment about acceptedButtons taking only
> 3 values ;) Y can give it all 5, like this:
>
> acceptedButtons: Qt.LeftButton | Qt.RightButton
>| Qt.MiddleButton | Qt.XButton1
> | Qt.XButton2
>
> and your MouseArea will start getting Press and Release events (plus
> DoubleClick, plus Press and Hold) for 'BackButton' and 'ForwardButton'.
> Here's my Test/Demo/Example program for you to try, and use as a model
> (just run it using "qmlviewer"): http://pastebin.kde.org/442676/ I set
> the expiration on that Paste at 30 days. It will be an official example,
> but with 27 buttons, in Qt5.
>
> On 03/18/2012 05:27 AM, Mark wrote:
>
> On Sun, Mar 18, 2012 at 1:56 AM, Xavier Sythe  wrote:
>
>> As far as I can recall, it was decided that the "back button" would be
>> implemented in the new Kickoff as support for the mouse's "back button", as
>> well as support for the "backspace" key, in conjunction with the other
>> keyboard navigation. (arrow keys)
>>
>>  I would appreciate Martin and Aaron's confirmation that this is the
>> finalized concept that will be implemented for 4.9.
>>
>>  Cheers,
>> Xavier
>>
>
>
>  I can confirm (or actually deny) that partly.
> They did indeed want to do that, however it was then figured out that QML
> didn't get all the mouse events required for that. That should be fixed in
> Qt5 but not in Qt4. So i'm afraid the mouse back/forward button support
> isn't going to be in anytime soon.
>
>
> Why isn't that documented on the Qt site
http://qt-project.org/doc/qt-4.8/qml-mousearea.html#acceptedButtons-prop?
That really sucks!

Nice to know that it's possible :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff, IMPORTANT FIXUP

2012-03-19 Thread Rick Stockton 

  
  
I'll top post this one:

OOPS! And PLEASE ignore my post, in Vol 45/Issue 46, where I talked
about this being requiring "just an easy change": This requires no
changes at all. It's already supported, and it even works back in
4.7.4. (Maybe earlier, but 4.7.4 is the earliest Release I have
"lying around" for test purposes.)

You only need to ignore the Doco Comment about acceptedButtons
taking only 3 values ;) Y can give it all 5, like this:

acceptedButtons: Qt.LeftButton | Qt.RightButton
   | Qt.MiddleButton |
Qt.XButton1 | Qt.XButton2 

and your MouseArea will start getting Press and Release events (plus
DoubleClick, plus Press and Hold) for 'BackButton' and
'ForwardButton'.
Here's my Test/Demo/Example program for you to try, and use as a
model (just run it using "qmlviewer"):
http://pastebin.kde.org/442676/ I set the expiration on that Paste
at 30 days. It will be an official example, but with 27 buttons, in
Qt5.

On 03/18/2012 05:27 AM, Mark wrote:

  On Sun, Mar 18, 2012 at 1:56 AM, Xavier
Sythe  wrote:

  As far as I can recall, it was decided that the "back button"
  would be implemented in the new Kickoff as support for the
  mouse's "back button", as well as support for the "backspace"
  key, in conjunction with the other keyboard navigation. (arrow
  keys)
  

  
  I would appreciate Martin and Aaron's confirmation that
this is the finalized concept that will be implemented for
4.9.
  
  
  Cheers,
  Xavier
   


I can confirm (or actually deny) that partly.
They did indeed want to do that, however it was then
  figured out that QML didn't get all the mouse events required
  for that. That should be fixed in Qt5 but not in Qt4. So i'm
  afraid the mouse back/forward button support isn't going to be
  in anytime soon.

  


  

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2012-03-18 Thread Rick Stockton 

  
  
On 03/18/2012 05:27 AM, Mark wrote:

  On Sun, Mar 18, 2012 at 1:56 AM, Xavier
Sythe  wrote:

  As far as I can recall, it was decided that the "back button"
  would be implemented in the new Kickoff as support for the
  mouse's "back button", as well as support for the "backspace"
  key, in conjunction with the other keyboard navigation. (arrow
  keys)
  

  
  I would appreciate Martin and Aaron's confirmation that
this is the finalized concept that will be implemented for
4.9.
  
  
  Cheers,
  Xavier
   


I can confirm (or actually deny) that partly.
They did indeed want to do that, however it was then
  figured out that QML didn't get all the mouse events required
  for that. That should be fixed in Qt5 but not in Qt4. So i'm
  afraid the mouse back/forward button support isn't going to be
  in anytime soon.


As for backspace being the back button. Don't know.
  

Since we keep getting chatter about this (and I own the bug :) -
If we really, REALLY need it for 4.9 -- two mouse buttons from a
"more mouse buttons Plztform Pugin patch on Qt5 was simultaneously
ported to into Qt 4.8.x last week. I don't remember if it was QNX or
OS-X, but it was one of those two. THAT was a feature enhancement,
not just a bugfix.

With all the arguments about Kickoff, maybe I should attempt to
Backport two more mouse buttons as a new feature to 4.8.x QML. The
work in such an "attempt" is entirely in arguing for the feature on
a minor Release update -- not in writing the code, which is about 4
lines, and duplicate to code which was integrated into Qt5
QDeclarative (QtQuick V2) long ago. No API changes, but values of
Qt::MouseButton which can be occur within a mouseArea would be
extended to add "Qt::XButton1" (synonym for Qt::BackButton, and
"Qt::XButton2" (Synonym for Qt::ForwardButton) to the current
Qt::LeftButton, Qt:RightButton, and Qt::MiddleButton values. (5
buttons instead of 3.)

There is also a possibility using the KDE versus Qt-Project "not yet
in Qt" patch collection to contain this enhancement.

KDE Management: Please advise me what, if anything, to do with this
possibility.
  

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2012-03-16 Thread Djuro Drljaca 
Hello,

well if there is going to be a QML version ... then the solution is simple
since you just have to change the QML file if you don't like the default
solution.

Regards,
Djuro Drljaca

On Fri, Mar 16, 2012 at 1:54 PM, Mark  wrote:

> On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin wrote:
>
>> this is my last mail to this thread
>>
>> On Friday 16 March 2012 12:29:45 Mark wrote:
>> > Things have changed quite a bit between the last discussion and now.
>> Back
>> > then the KDE version had both the breadcrumbs and the back button. Right
>> > now we have a new KDE version that only has the breadcrumbs. So now is
>> the
>> > time when users start noticing something is different and that they
>> perhaps
>> > might miss something or not.
>> I'm not sure what you mean with things have changed... First of all the
>> behavior had been changed for version 4.7 which got released in July 2011.
>> Furthermore for us developers back in December the current version was
>> already
>> 4.8.
>>
>> If you read the discussion you probably noticed that there is work going
>> on to
>> rewrite Kickoff for 4.9. Given that I do not understand why we should
>> discuss
>> a user interface whose code will be dropped.
>>
>> Cheers
>> Martin
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
> Jup, i'm mixing up versions again :)
> It's difficult for me to keep track of which thing changed where when i'm
> experimenting with the code, using git for some other parts and
> the distribution version for the remaining part.
>
> I know that there is going to be a QML version of kickoff that you're
> making and that rocks!
>
> As Aaron said, there is no "right answer" here and i honestly don't know
> what's the best way to go. The current situation isn't ideal, the future
> situation isn't ideal and it never was ideal, so i guess we should just
> "live with it" for the time being.
>
> Regards,
> Mark
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2012-03-16 Thread Mark 
On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin  wrote:

> this is my last mail to this thread
>
> On Friday 16 March 2012 12:29:45 Mark wrote:
> > Things have changed quite a bit between the last discussion and now. Back
> > then the KDE version had both the breadcrumbs and the back button. Right
> > now we have a new KDE version that only has the breadcrumbs. So now is
> the
> > time when users start noticing something is different and that they
> perhaps
> > might miss something or not.
> I'm not sure what you mean with things have changed... First of all the
> behavior had been changed for version 4.7 which got released in July 2011.
> Furthermore for us developers back in December the current version was
> already
> 4.8.
>
> If you read the discussion you probably noticed that there is work going
> on to
> rewrite Kickoff for 4.9. Given that I do not understand why we should
> discuss
> a user interface whose code will be dropped.
>
> Cheers
> Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
Jup, i'm mixing up versions again :)
It's difficult for me to keep track of which thing changed where when i'm
experimenting with the code, using git for some other parts and
the distribution version for the remaining part.

I know that there is going to be a QML version of kickoff that you're
making and that rocks!

As Aaron said, there is no "right answer" here and i honestly don't know
what's the best way to go. The current situation isn't ideal, the future
situation isn't ideal and it never was ideal, so i guess we should just
"live with it" for the time being.

Regards,
Mark
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2012-03-16 Thread Martin Gräßlin 
this is my last mail to this thread

On Friday 16 March 2012 12:29:45 Mark wrote:
> Things have changed quite a bit between the last discussion and now. Back
> then the KDE version had both the breadcrumbs and the back button. Right
> now we have a new KDE version that only has the breadcrumbs. So now is the
> time when users start noticing something is different and that they perhaps
> might miss something or not.
I'm not sure what you mean with things have changed... First of all the 
behavior had been changed for version 4.7 which got released in July 2011. 
Furthermore for us developers back in December the current version was already 
4.8.

If you read the discussion you probably noticed that there is work going on to 
rewrite Kickoff for 4.9. Given that I do not understand why we should discuss 
a user interface whose code will be dropped.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-31 Thread Martin Gräßlin 
On Saturday 31 December 2011 09:30:25 Aaron J. Seigo wrote:
> On Wednesday, December 28, 2011 09:42:35 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=
> > Yes and that's why I moved it to the left in the new implementation.
> 
> note that this then puts it in a different location to all the other headers
> in the other tabs.
> 
> so you switch from Favourites to Applications -> header switches location.
> Applications to System -> header swtiches location again.
> 
> if the breadcrumbs are moved to the left and/or get a specialized visual
> treatment (neither of which are bad ideas imho) then the other headers
> should similarly be adjusted for consistency across the tabs.
so far I synchronized the position with other Plasma elements and moved the 
headers into the center. Personally I would prefer to have a consistent UI 
throughout all Plasma elements (at least for the default shipped widgets).

So the question is whether the breadcrumbs need to be moved from Left to 
Center. I will give that a try, but are not sure whether it is a good idea as 
it causes changes when traversing the menu.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-28 Thread Martin Gräßlin 
On Tuesday 27 December 2011 23:36:54 Matthew Dawson wrote:
> 1) The back button was a much larger button to hit.
>   According to Fitt's Law[1], the smaller a target is to hit, the longer 
> it
> takes.  The breadcrumbs, being smaller, decreases the speed at which someone
> can hit the target.  It is readily apparent to me, as I only recently got
> introduced to it.
Fitt's Law is only a valid argument iff the back button is directly on the 
left screen edge. So it is fine for our default, for everything else the back 
button is in fact rather bad due to Fitt's Law.
> 
> 2) The position of the breadcrumbs is on the upper right hand corner.
>   People will first look for information to the upper left hand part of 
> the
> screen.  With the breadcrumbs positioned where they are, its first of all
> hard to find compared to the back button.  I can't remember if people
> brought up with RTL languages see upper right hand first, but at least for
> LTR it is.
Yes and that's why I moved it to the left in the new implementation.
> Thoughts?  If these ideas sound useful, I'll try to cook up a patch to
> implment them.
the current implementation will be thrown away soon. So don't waste your time 
on working with the C++ code. If you want to work on the QML based kickoff you 
need to checkout the branch kickoff-qml.

In general the discussion seems to be at a mood point if people do not know 
the work which is going on.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: Breadcrumbs in Kickoff

2011-12-27 Thread Martin Gräßlin 
On Tuesday 27 December 2011 20:16:48 Kevin Kofler wrote:
> Martin Gräßlin wrote:
> > Which significant number of critical comments? How many users have
> > commented here in the thread and reported bugs? 5? 10? 20? We are talking
> > about a feature which will be used by millions of users. If we get to a
> > thousand users complaining we can start to think about significant
> > numbers.
>
> FYI, we've got a bunch of complaints on #fedora-kde about this. Not everyone
> affected goes post to plasma-devel.
define a bunch. 20 people per day? 50 per day? One per month? Seriously we
have millions of users and I doubt that Fedora KDE users on IRC is our primary
target group for Kickoff. If a user knows the word IRC I would say he needs a
different launcher: recommend them to use krunner, they will like it :-)

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-27 Thread Kevin Kofler 
Martin Gräßlin wrote:
> Which significant number of critical comments? How many users have
> commented here in the thread and reported bugs? 5? 10? 20? We are talking
> about a feature which will be used by millions of users. If we get to a
> thousand users complaining we can start to think about significant
> numbers.

FYI, we've got a bunch of complaints on #fedora-kde about this. Not everyone 
affected goes post to plasma-devel.

Kevin Kofler

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-21 Thread Rick Stockton 

On 01/-10/-28163 11:59 AM, Xavier Sythe wrote:

Alexey made several valid points

<< SNIP >>
Regardless of whether the back button is reinstated, I will support 
adding the mouse's back button as a way to go back.  The back button 
is a staple of modern UI, featured prominently in all file/web browsers.
Xavier, thanks for supporting the 'alternative compromise'. We'll try to 
get that done for 4.9. http://bugs.kde.org/show_bug.cgi?id=289519


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-21 Thread Martin Gräßlin 
On Wednesday 21 December 2011 21:33:52 Martin Klapetek wrote:
> 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,
which is just a MouseArea set on the view which already has all the code to go 
up. Trivial, easy to maintain, doesn't influence any other code of Kickoff.
> isn't
> the back button then just like 10 lines of qml code? Ie. just hook the
> onClick: to the "one-level-back" action?
Nope: it influences the layout. It is not trivial to add with my current 
design of Kickoff in QML. As a matter of fact we would also have to consider 
to put the button on the right when Kickoff is on the right edge. That 
requires strong adjustments on the layout as well as choosing a different 
arrow element.

So no, this is clearly a non-trivial change with lots of potential impact for 
future development. Remember: if we add it we have to maintain it. It might 
hinder future changes, which would be bad.

I wrote it in another mail in this thread: it increases the complexity of the 
code base. Nothing I like.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-20 Thread Martin Gräßlin 
On Wednesday 21 December 2011 00:51:45 Alexey Chernov wrote:
> On 20 дек 2011 11:20:23 Aaron J. Seigo wrote:
> > On Tuesday, December 20, 2011 00:33:20 4ernov wrote:
> > > unclear why you so against to approve such a work.
> >
> > i think it is perfectly fine if you wish to create a modified kickoff and
> > ship it as a separate plasmoid. this is what we've done for a few
> > different
> > plasmoids, including the tasks plasmoid (and that's ended up turning out
> > rather well for everyone i think :).
>
> No, I mean a contribution with config option or something which can return
> the Back button. I don't think it's perfect idea to fork kickoff because of
> one function.
but that's the point. Now in a month someone else wants something completely
different. Then it's still not the perfect idea to fork Kickoff because of one
function. A month later the next config option creeps in and another one and
another one. And a nice small applet becaume a Frankenstein.

Either you decide that no non-valid config options go in or you have
discussions about it each other day.
>
> > i do not want plasma desktop to become a collection of everyone's pet
> > features with a thousand configuration tweaks.
>
> Exactly. I agree. But as I remember Martin said that we're discussing only
> config option and reverting to Back button wasn't an option. I think, nobody
> also wants Plasma desktop to become a collection of wrong decisions, it's
> even worse.
Yes, I said we can discuss the need of a config option. For that we require
good arguments why such an option is required. That has not yet presented
here. Neither we can do it, nor but it was there is a good argument.
>
> > the back button was not
> > serving everyone well (we got lots of feedback on it ...)
>
> I didn't say the Back button was ideal. I think a serious usability research
> should be performed to find the better solution instead of it. And I can't
> believe any usability expert could suggest breadcrumbs instead of back
> button as it's just against the basic things one could learn in usability.
So you are a usability expert? I didn't know that. I am no usability expert,
because of that I do not argue with usability. (Just look through my mails you
will nowhere find that I say the breadcrumbs are better and the back button is
worse from a usability point of view). If you have not studied usability, I
would appreciate that you don't pull such arguments. It a serious field of
research and we should not do like we know better.
> As to me, my solution is: keep both Back button and breadcrumbs. Here's my
> arguments:
> - no config and no tweaks required
> - users can use both ways
> - no redundancy or duplication as it's just two methods to reach the same
> result (there're thousands of examples with such implementations, e.g. same
> features in main menu, toolbar and context menus in one application)
I'm sorry but all your examples are bad ones. Let's consider them:
* main menu is normally dropped. Finding an option there is a complicated
task. See for example Unity which basically removed the menu completely.
* context menu you have to explicitly trigger, you have to know that the
functionality is there.

With Kickoff we are talking about two always visible and directly reachable UI
elements. This is something completely different. We also have to consider how
close these UI elements are. Given the new QML design they would border each
other. That is one of my main concerns that it visually clutters the view,
makes them inconsistent (only one of four views uses the back button) and
confusing. I don't see why the average user would need this always there. To
me this looks like you realized that you don't get your config option and now
you try to adjust your argument ;-)
> - minimum of code required
this is just not true. This would significantly increase the code size. See my
other mail on that subject. As I wrote I expect an increase of code size for
one QML file by at least 10 %.
>
> I don't mean that it's a bad code or something and I respect all the efforts
> of Martin and whole Plasma team to improve navigation, to find some better
> decisions. But I think such a things should be discussed especially given a
> significant number of critical comments. If something was wrong I don't see
> any problems to solve it.
Which significant number of critical comments? How many users have commented
here in the thread and reported bugs? 5? 10? 20? We are talking about a
feature which will be used by millions of users. If we get to a thousand users
complaining we can start to think about significant numbers.

A small anectode: we had a recent event in the state where I live. In our
state capital the German government and the Deutsche Bahn want to build a new
station. It will take many years to build it and will cost several billions €.
Over the last year there were many demonstrations in the captial with
thousands of people protesting against the station. Since the last elec

Re: Re: Breadcrumbs in Kickoff

2011-12-20 Thread Martin Gräßlin 
On Tuesday 20 December 2011 00:33:20 4ernov wrote:
> I also can't see a reason to be so much against any suggestion on
> improve the situation with Back button itself. If it's a question of
> resources to implement e.g. a config option than, for example I can
> work at it. I think nobody wants to spoil new code or new navigation
> architecture or whatever so it would be done very carefully. It's
> unclear why you so against to approve such a work.
Up to now nobody gave a proper reason *why* we should add a back button. Just 
because we can is no reason, sorry.

Adding the back button requires a config option. There is clearly no need for 
such an option. How should normal users understand such an option? This is a 
severe case of featuritis and should not be found in an element of our primary 
user interface. This has been practice for Plasma for quite some time. Even 
the two existing config options are rather questionable. I added support for 
them in kickoff-qml but since then I have been thinking about dropping them 
again.

But config option is not the only problem. It's also about maintaining the 
code and being able to adjust it in future. Adding such an option would 
significantly increase the code size. I expect that the related file would 
gain at least 10 % more code and an increased complexity level by at least 
two. So maintaining cost significantly increase. And is it worth that for a 
feature nobody can argue why it is needed?

To me it is clear that the proper solution is the one Aaron suggested.

Thanks for understanding why we have to do what is the best compromise out of 
what is best for our user base and our code base.

Kind Regards
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: Re: Breadcrumbs in Kickoff

2011-12-19 Thread Rick Stockton 

  
  
On 01/-10/-28163 11:59 AM, Martin Gräßlin wrote:

  
  
  Hey Rick,
  On Sunday 18 December 2011 09:29:36 Rick
Stockton wrote:
  > On 01/-10/-28163 11:59 AM, Aaron J.
Seigo wrote:
  > 
  > Aaron, my words were unclear. If you and
Martin are willing to put this
  > into the 4.8.x Series, it CAN be done,
but we _must_ use the name which
  > already exists. 'Xbutton1' == the Back
Button, the other two names will
  > be synonyms for 'XButton1' in Qt5.
'XButton1' will still be present, and
  > we can stay Source-compatible across
both Qt Versions by using THAT name.
   
  the earliest point in time to ship it is 4.9
which will be based on my new QML based implementation. And
there seems to be a problem... MouseArea does not know anything
except the three standard buttons[1].
  

With that 3-button limitation, it HAS to wait for 4.9 to get the
buttons (in Qt5). And thanks, YIKES, for showing me the 'QML only
has 3 buttons' problem! I'll go write the enhancement into Qt --
I've still got at least a couple of weeks before API freeze.
  

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: Breadcrumbs in Kickoff

2011-12-18 Thread Martin Gräßlin 
Hey Rick,
On Sunday 18 December 2011 09:29:36 Rick Stockton wrote:
> On 01/-10/-28163 11:59 AM, Aaron J. Seigo wrote:
> 
> Aaron, my words were unclear. If you and Martin are willing to put this
> into the 4.8.x Series, it CAN be done, but we _must_ use the name which
> already exists. 'Xbutton1' == the Back Button, the other two names will
> be synonyms for 'XButton1' in Qt5. 'XButton1' will still be present, and
> we can stay Source-compatible across both Qt Versions by using THAT name.

the earliest point in time to ship it is 4.9 which will be based on my new QML 
based implementation. And there seems to be a problem... MouseArea does not 
know anything except the three standard buttons[1]. So seems like it's not 
possible with the back mouse button. Middle button might be an option but 
might be rather unexpected.

I will try to improve the keyboard navigation, though.

Cheers
Martin

[1] http://doc.qt.nokia.com/4.8-snapshot/qml-mousearea.html#acceptedButtons-
prop


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-18 Thread Rick Stockton 

On 01/-10/-28163 11:59 AM, Aaron J. Seigo wrote:

Aaron, my words were unclear. If you and Martin are willing to put this 
into the 4.8.x Series, it CAN be done, but we _must_ use the name which 
already exists. 'Xbutton1' == the Back Button, the other two names will 
be synonyms for 'XButton1' in Qt5. 'XButton1' will still be present, and 
we can stay Source-compatible across both Qt Versions by using THAT name.


'XButton2' == 'ForwardButton' == 'ExtraButton2' in the exact same way. 
'XButton2' already exists in Qt4; we can use it NOW, and it will be 
present in Qt5 as well. There are far fewer instances, in KDE programs, 
where a 'Forward' Button makes sense. But they do exist (Amarok "forward 
to the next song on my CD", for example.) I don't know how many have 
actual implementations of these two buttons. IIRC, Konq DOES have them both.


< Start of 'too much information' >
The guts of my "more mouse buttons" feature (see 
https://bugs.kde.org/show_bug.cgi?id=34362#c34) adds a capability for 
even higher buttons, starting from 'ExtraButton3'. The maximum possible 
mouse button in Qt is 'ExtraButton24', although the evdev driver (if 
used in Wayland OR X11) runs out of Valuators after ExtraButton20. 
(Kernel "input.h" allows for only 16 button values, but it doesn't 
consume 4 'buttons' for the tilt wheel. So, if we speak in terms of 
Wayland, or X11 using the evdev Driver instead of the legacy "mouse" 
Driver, the biggest possible mouse has 16+4 = 20 "buttons".)



Xavier Sythe should use one of the proper KDE enhancement request 
schemes- he should open a bug, of type 'enhancement'. Using that 
process, allows for focused feedback WITHOUT getting into a long Thread 
of personal attacks and counter-attacks on a list where he DOESN'T 
BELONG. Martin, if you decide it's worth doing but don't take it 
yourself, go ahead and assign to me.



On Saturday, December 17, 2011 16:12:18 Rick Stockton wrote:

The names 'BackButton and 'ExtraButton1' aren't defined until Qt5, but
'XButton1' is already present in Qt 4.7 (and many earlier 4.x Releases, as
well)

regardless of what is done elsewhere (breadcrumbs, etc) this would be a fine
idea.

Qt won't support more mouse buttons until Qt5, but perhaps we could put an x-
specific bit of code in there until then.


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-17 Thread Rick Stockton 

  
  
Martin, I have an idea- even though I never even looked at Kickoff.
(Before writing this, I SHOULD have looked - but I don't have time
right now.) It seems to me that all of the layout issues, and the
GUI focus issues, of doing a GUI "back button" can be avoided: Just
listen for a QMouseEvent with QMouseEvent::button() value of:
 'XButton1' == 'BackButton' == 'ExtraButton1', and execute "back!"
whenever the event occurs in valid context.

The names 'BackButton and 'ExtraButton1' aren't defined until Qt5,
but 'XButton1' is already present in Qt 4.7 (and many earlier 4.x
Releases, as well). Implementing this, Xavier (and others) would be
able to buy and use a mouse with Thumb buttons, "back" and
"forward", and just whack the buttons. No mouse movements at all,
and no GUI issues for us. Am I am guilty of "old style" thinking, or
does this enhancement make sense to you?

My feeling is like a famous statement, from one of the bad guys in a
famous 'Spaghetti Western': "GUI Buttons? We Don't need no stinkin'
GUI Buttons !!!"

(Perform an action on the Button Event, but leave the GUI scheme as
is: using breadcrumbs exclusively) 





On 01/-10/-28163 11:59 AM, Xavier Sythe wrote:
Actually, the breadcrumbs don't really need to be
  removed.
  I merely see the need to reinstate the back button.
  "I personally do not see any need for the back button any more."
  
  It's mostly a user experience perspective.
  
  It's a simple fact that it requires less mouse movement, hence,
  less time, to click the back button, then it does to move your
  mouse to the top of the menu, and use the breadcrumbs.  Why? 
  Because the back button extends all the way down the length of the
  menu.  Instead of having to move your mouse to the top of the
  menu, then to the left, you can simply move it to the left and
  click the button.
  
  
  "The
  breadcrumbs add high value to Kickoff. It makes navigation in a
  folder like
  structure like the application menu more convenient and much more
  consistant
  with other parts of KDE applications, e.g. Dolphin's..."
  
  Just like in Dolphin, this menu style would feature both
  breadcrumb navigation, and a back button.
  
  Would you support removing the back button from Dolphin, in favour
  of just breadcrumbs?
  I doubt that anyone would support that.
  
  I've chatted briefly with the KDE Usability Team, and they
  actually seemed to agree with me.
  
  Well some users might stick to the breadcrumb navigation, the
  majority of users from previous versions of KDE are accustomed to
  the back button, and appreciate its use, both in Kickoff as well
  as in Dolphin.  Including both types of navigation will ensure
  that nobody complains, and presumably, lead to a better overall
  user experience.
  
  Thanks,
  Xavier Sythe
  
  
  
  
  
  On Fri, Dec 16, 2011 at 2:12 PM, Martin
Gräßlin 
wrote:

  On Thursday 08 December 2011 16:01:33 Xavier
Sythe wrote:
> Nearly two months ago, I contacted him, and asked him
to reverse the
> controversial commit.
> He has yet to reply.
  
  Please understand that not each developer has the time to
  answer personal
  requests. You state yourself that it is controversial. Just
  imagine each user
  disliking the feature sending a mail to Kevin. That just
  doesn't scale.
  
  Asking to revert the feature is to be honest non-constructive
  criticism. Like
  all other decisions on the default user interface they are
  done with care. The
  breadcrumbs add high value to Kickoff. It makes navigation in
  a folder like
  structure like the application menu more convenient and much
  more consistant
  with other parts of KDE applications, e.g. Dolphin's
  breadcrumb navigation.
  
  Just because you (and others) dislike the new feature it does
  not justify to
  revert the commit. There are also users liking the feature, so
  how should we
  suit both groups? Now please don't state that we need an
  option for that. This
  is not possible as the code gets too complex and too difficult
  to maintain.
  >
> When I asked the #KDE IRC channel about this, I was
told to contact the
> members of this mailing list, to see if I could get the
commit reversed.
  
  Reverting the commit is clearly not an option. But what would
  you say about
  improving the

Re: Re: Breadcrumbs in Kickoff

2011-12-17 Thread todd rme 
On Sat, Dec 17, 2011 at 5:02 PM, Martin Klapetek
 wrote:
> So if we went down the road of making kickoff less
> "deep", then imho breadcrumb looses its purpose and back button would be
> just enough.

I don't think this is possible.  The application directory structure
is defined by distributions, not be KDE.  How KDE uses the directory
structure is determined by FDO specs, so KDE cannot really
unilaterally ignore them.

At least in my distro applications have 3 levels (including "all applications").

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-17 Thread todd rme 
On Sat, Dec 17, 2011 at 4:18 PM, Martin Gräßlin  wrote:
>> Would you support removing the back button from Dolphin, in favour of just
>> breadcrumbs?
>> I doubt that anyone would support that.
> I thought about it and I had to open Dolphin to verify that there is a back
> button at all. I doubt I have used the back button during the last few years.
> So yes I would support that.

I would not support this, but for a different reason.  The "back"
button in the kickoff menu isn't really a "back" button in the same
way the Dolphin one is.

The dolphin back button, like back buttons in every other file manager
or web browser I have ever used,  takes you to the previously-visited
directory, not matter how far that directory may be from your current
location.

The "back" button in kickoff did not work like this.  Instead, it took
you to the parent directory of the current directory.  In that way it
is much more like Dolphin's "Up" button.  This button in Dolphin, and
other file managers and web browsers, takes you to the parent
directory of the current directory.  Konqueror has an "up" button by
default.  In Dolphin, however, this button has been removed in favor
of using the breadcrumb bar.  So if we are comparing dolphin and
kickoff, then the breadcrumbs in kickoff are much more likely dolphin,
while the old version is more like konqueror.  The button is still
available in Dolphin, I assume for people who use the traditional
navigation bar, but it is not in the toolbar by default.

I think removing the up button in dolphin and kickoff was a good idea.
 I think removing the back button in dolphin, however, would not be,
since it makes it much quicker to move to directories that are not
direct parents of the current directory (I us it for this purpose a
lot).

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-17 Thread Martin Klapetek 
On Sat, Dec 17, 2011 at 17:02, Martin Klapetek wrote:

>
> Having both types in kickoff at the same time seems a bit wrong to me too.
> Having an option to switch that on the other hand would be more sensible. I
> would suggest to find someone who can implement it in Martin's newest
> kickoff branch in such way, that it won't be more work to maintain. Maybe
> even the whole navigation system could be modified to fit both options (I
> don't know how it currently works)? But again, as Martin clearly stated
> he's not in favor of doing this, find someone who will do it and have him
> work together with Martin.
>

Now that I'm reading what I wrote, I realize it's actually a nonsense
(sorry was preoccupied with other stuff).

Switching to either breadcrumb or the back button is wrong. Both bring
something valuable. So if there should be any option, then I'd add only
"Show back button", but do not switch the breadcrumbs off. As for the rest
- that still holds :)

--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-17 Thread Martin Klapetek 
Hi,

I don't have any strong opinions to either solution, but I just want to
state my views on this discussion.




> > It's a simple fact that it requires less mouse movement,
> If you state "facts" you have to prove them. Where is your usability study
> showing that a movement to the left is better than a movement to the top?
>

In my opinion, the breadcrumbs make sense with deep/long paths. My kickoff
from 4.8/master has everything only one level deep, therefore making the
breadcrumb navigation rather useless (because you can click only the "All
Applications" anyway). So if we went down the road of making kickoff less
"deep", then imho breadcrumb looses its purpose and back button would be
just enough.

Then again, it at least shows where you currently are, so if you for
example close kickoff with some category opened and you reopen kickoff, you
can immediately see "All Applications > Internet" so you know where you
are. Also there are things like Wine which pretty much recreates the
Windows Start menu structure, so you can get 5 levels deep in notime.

As for the mouse movement - if one uses larger kickoff, imho it indeed is
easier to move the mouse just few pixels to the left than moving it all the
way across (consider laptop's touchpad).



> > Would you support removing the back button from Dolphin, in favour of
> just
> > breadcrumbs?
> > I doubt that anyone would support that.
> I thought about it and I had to open Dolphin to verify that there is a back
> button at all. I doubt I have used the back button during the last few
> years.
> So yes I would support that.
>

The back button in Dolphin is actually /very/ useful, consider you're
working in

/home/user/work/project1/subproject3/source/

then you want to move to

/home/user/work/

do something (copy a file) and then back to the first one. So you click the
"work/" in breadcrumb and then you can either navigate all the folders OR
simply click the Back button. I use it every single day ;)


> >
> > I've chatted briefly with the KDE Usability Team, and they actually
> seemed
> > to agree with me.
> Sorry to say: but with whom have you talked? Not everybody who says he is
> in
> the KDE Usability Team is a usability expert but just a user who thinks he
> understands usability. That's quite a difference.
>

I agree that you should either post a log of your conversation or forward
the messages with names. Otherwise it's just a blunt statement.


>
> And what do you mean with "seemed"? They either agree or don't agree.
> >
> > Well some users might stick to the breadcrumb navigation, the majority of
> > users from previous versions of KDE are accustomed to the back button,
> and
> > appreciate its use, both in Kickoff as well as in Dolphin.  Including
> both
> > types of navigation will ensure that nobody complains, and presumably,
> lead
> > to a better overall user experience.
> Do you have any facts that this is actually the case? I don't have any
> statistics validating or disvalidating your statement. The only thing I can
> tell you is that there is a vocal minority requesting to add the feature
> back[2]. With less than ten users posting to the bug report, I am sorry to
> tell you that there seems no demand for this feature. (Btw. don't even try
> to
> rally now that users post to the bug report. If that is going to happen I
> will
> make sure that the bug gets made read only).
>

Having both types in kickoff at the same time seems a bit wrong to me too.
Having an option to switch that on the other hand would be more sensible. I
would suggest to find someone who can implement it in Martin's newest
kickoff branch in such way, that it won't be more work to maintain. Maybe
even the whole navigation system could be modified to fit both options (I
don't know how it currently works)? But again, as Martin clearly stated
he's not in favor of doing this, find someone who will do it and have him
work together with Martin.

--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

2011-12-17 Thread Martin Gräßlin 
Hi,

given that I basically told you not to write developers personally, I do not
understand why you sent the mail to me instead of the mailinglist. I forwared
your mail to the mailinglist and please send further mails also to the list if
you are really interested in discussing this.

Please also don't tofu, it makes discussions difficult to read[1].

On Friday 16 December 2011 19:04:48 Xavier Sythe wrote:
> Actually, the breadcrumbs don't really need to be removed.
> I merely see the need to reinstate the back button.
> "I personally do not see any need for the back button any more."
>
> It's mostly a user experience perspective.
I quite agree it's all about user experience. I think we should not have
redundant elements in our primary user interface. This is confusing. Also the
back button does not exist in any other part of the Plasma desktop or any
other KDE application.
>
> It's a simple fact that it requires less mouse movement,
If you state "facts" you have to prove them. Where is your usability study
showing that a movement to the left is better than a movement to the top?
> Would you support removing the back button from Dolphin, in favour of just
> breadcrumbs?
> I doubt that anyone would support that.
I thought about it and I had to open Dolphin to verify that there is a back
button at all. I doubt I have used the back button during the last few years.
So yes I would support that.
>
> I've chatted briefly with the KDE Usability Team, and they actually seemed
> to agree with me.
Sorry to say: but with whom have you talked? Not everybody who says he is in
the KDE Usability Team is a usability expert but just a user who thinks he
understands usability. That's quite a difference.

And what do you mean with "seemed"? They either agree or don't agree.
>
> Well some users might stick to the breadcrumb navigation, the majority of
> users from previous versions of KDE are accustomed to the back button, and
> appreciate its use, both in Kickoff as well as in Dolphin.  Including both
> types of navigation will ensure that nobody complains, and presumably, lead
> to a better overall user experience.
Do you have any facts that this is actually the case? I don't have any
statistics validating or disvalidating your statement. The only thing I can
tell you is that there is a vocal minority requesting to add the feature
back[2]. With less than ten users posting to the bug report, I am sorry to
tell you that there seems no demand for this feature. (Btw. don't even try to
rally now that users post to the bug report. If that is going to happen I will
make sure that the bug gets made read only).

Please understand that we have to develop software which suits most of our
users. This means that we cannot make all users happy and we are not always
able to add all the features users want. We have to care about more than just
adding features.

Kind Regards
Martin Gräßlin

[1] http://www.rfc1855.net/
[2] https://bugs.kde.org/show_bug.cgi?id'4489
>
> Thanks,
> Xavier Sythe
>
> On Fri, Dec 16, 2011 at 2:12 PM, Martin Gräßlin  wrote:
> > On Thursday 08 December 2011 16:01:33 Xavier Sythe wrote:
> > > Nearly two months ago, I contacted him, and asked him to reverse the
> > > controversial commit.
> > > He has yet to reply.
> >
> > Please understand that not each developer has the time to answer personal
> > requests. You state yourself that it is controversial. Just imagine each
> > user
> > disliking the feature sending a mail to Kevin. That just doesn't scale.
> >
> > Asking to revert the feature is to be honest non-constructive criticism.
> > Like
> > all other decisions on the default user interface they are done with care.
> > The
> > breadcrumbs add high value to Kickoff. It makes navigation in a folder
> > like
> > structure like the application menu more convenient and much more
> > consistant
> > with other parts of KDE applications, e.g. Dolphin's breadcrumb
> > navigation.
> >
> > Just because you (and others) dislike the new feature it does not justify
> > to
> > revert the commit. There are also users liking the feature, so how should
> > we
> > suit both groups? Now please don't state that we need an option for that.
> > This
> > is not possible as the code gets too complex and too difficult to
> > maintain.
> >
> > > When I asked the #KDE IRC channel about this, I was told to contact the
> > > members of this mailing list, to see if I could get the commit reversed.
> >
> > Reverting the commit is clearly not an option. But what would you say
> > about
> > improving the breadcrumbs in Kickoff? Getting them into a state that you
> > want
> > to use them and not the out-of-place back button?
> >
> > Have a look at my recent blog post [1] about the work on Kickoff for 4.9.
> > It
> > is easy to give this version a try, it installs alongside the existing
> > Kickoff. I personally do not see any need for the back button any more.
> >
> > Kind Regards
> > Martin Gräßlin
> >
> > New Kickoff Maintainer after branch merge