Re: Re: Breadcrumbs in Kickoff, IMPORTANT FIXUP
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 m...@sythe.me 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, IMPORTANT FIXUP
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 m...@sythe.me 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: Breadcrumbs in Kickoff
On Sun, Mar 18, 2012 at 1:56 AM, Xavier Sythe m...@sythe.me 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
Hi Mihai, there has already been a lengthy discussion about breadcrumbs in Kickoff back in December [1]. I don't think anyone is interested in having yet another discussion about that topic. Thanks. Martin Gräßlin [1] http://mail.kde.org/pipermail/plasma-devel/2011-December/018184.html On Thursday 15 March 2012 11:20:43 Mihai Dobrescu wrote: Hello, IMHO, when a user makes a request, he will not perform a market study on his demand. He knows his needs and he doesn't ask, nor speaks, for other users hand. I feel an important amount of stress from the developers part, regarding the code involved. From the user part this is unknown. As professional developer, the easy to use a feature is, the harder might be to implement in the code. When I became software developer, I've sworn to satisfy my customers, of course when possible and within the feasible limits. So, I would not reject a requested feature unless I have good technical reasons to prevent it, based on the argument of complexity of code. Of course, maintenance is a good reason to reject when not enough resources are present, in order to support that feature (is this the case?). So, as KDE user, I can't give any statistics, polls, whatever in favor or against this button. I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to _me_. Form _my_ point of view, breadcrumbs are also useful, as a shortcut, when I need to jump over some elements in the path. So, the back button and breadcrumbs, although seem redundant, they are not, _to me_. I would use the 'back' button in 90% of cases. It is the very same case with Dolphin (the 'Up' button vs the path breadcrumbs), again, _for me_. BTW, not all users that miss the button will complain. Some devs say that these messages are lose of time for them. I can say using the breadcrumbs in the KickOff menu make me losing time too, for the sole reason it is unnatural _to me_ to use it there. Also, user feedback is not a lose of time. Although not many users express their gratitude for the developers work, because, _it seems_, the human nature is to complain about things not working or things not done. Sometimes it should happen. I _need_ to tell you, all the KDE team, that I love your work, some may say _imperfect_, but _great_ I say, knowing the effort you put in keeping it as close as possible to our needs. KDE is, _in my opinion_, well designed, flexible to be extended, clean and visually appealing. And OPEN. Making Plasma and Plasmoids is a good move. It's in the spirit of Linux and its customizability. I hope you keep up this good work for long. Thank you, Mike. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Breadcrumbs in Kickoff
On Fri, Mar 16, 2012 at 11:47 AM, Martin Gräßlin mgraess...@kde.org wrote: Hi Mihai, there has already been a lengthy discussion about breadcrumbs in Kickoff back in December [1]. I don't think anyone is interested in having yet another discussion about that topic. Thanks. Martin Gräßlin [1] http://mail.kde.org/pipermail/plasma-devel/2011-December/018184.html On Thursday 15 March 2012 11:20:43 Mihai Dobrescu wrote: Hello, IMHO, when a user makes a request, he will not perform a market study on his demand. He knows his needs and he doesn't ask, nor speaks, for other users hand. I feel an important amount of stress from the developers part, regarding the code involved. From the user part this is unknown. As professional developer, the easy to use a feature is, the harder might be to implement in the code. When I became software developer, I've sworn to satisfy my customers, of course when possible and within the feasible limits. So, I would not reject a requested feature unless I have good technical reasons to prevent it, based on the argument of complexity of code. Of course, maintenance is a good reason to reject when not enough resources are present, in order to support that feature (is this the case?). So, as KDE user, I can't give any statistics, polls, whatever in favor or against this button. I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to _me_. Form _my_ point of view, breadcrumbs are also useful, as a shortcut, when I need to jump over some elements in the path. So, the back button and breadcrumbs, although seem redundant, they are not, _to me_. I would use the 'back' button in 90% of cases. It is the very same case with Dolphin (the 'Up' button vs the path breadcrumbs), again, _for me_. BTW, not all users that miss the button will complain. Some devs say that these messages are lose of time for them. I can say using the breadcrumbs in the KickOff menu make me losing time too, for the sole reason it is unnatural _to me_ to use it there. Also, user feedback is not a lose of time. Although not many users express their gratitude for the developers work, because, _it seems_, the human nature is to complain about things not working or things not done. Sometimes it should happen. I _need_ to tell you, all the KDE team, that I love your work, some may say _imperfect_, but _great_ I say, knowing the effort you put in keeping it as close as possible to our needs. KDE is, _in my opinion_, well designed, flexible to be extended, clean and visually appealing. And OPEN. Making Plasma and Plasmoids is a good move. It's in the spirit of Linux and its customizability. I hope you keep up this good work for long. Thank you, Mike. ___ 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 Martin, 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. Back in December i fully agreed with you that the back button is redundant and the breadcrumbs can be used just as well. However, right now since KDE 4.8 was released I'm slowly realizing i miss something in the menu. I miss an option to just go back. No, i'm not trying to convince you that we need the full vertical bar back to go back, that really seemed totally out of place anyway. But right now i do think that having a back button would be better. The breadcrumbbar does allow you to go back, but it's kinda making me thing when i press it where do i need to go back to, main menu or.. and i don't want to think about that in a menu! I just want to go back. Right now, to me, it even seems like the breadcrumbbar is out of place in a menu. It's nice but just not working intuitively in a menu. Perhaps we do need to have a new fresh discussion about it since the impact is just becoming clear to the kde users now and in the coming months when the next (K)Ubuntu and Fedora get released. Perhaps a topic on the kde forum should be created. You might think the back button is of no use, but others might think differently. The discussion in december has shown that, now it's boiling up again and it will boil up more once Kubuntu and Fedora have their next release. The old situation wasn't perfect, but the current situation is not perfect as well. We need something in between. Kind regards, Mark ___ Plasma-devel mailing list Plasma-devel@kde.org
Re: Re: Breadcrumbs in Kickoff
notethis is my last mail to this thread/note 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: Breadcrumbs in Kickoff
On Friday, March 16, 2012 12:29:45 Mark wrote: but others might think differently. here is the most useful bit of all three emails so far in the resurrected thread. there is going to be no right answer because no matter what the choice is someone will differ. if we have both ways? it's cluttered and hard to use. have one way? the other way is better. yes, it will be different people objecting, but it's stile someone. and i'm going to assume you don't believe you are more valuable and important than others here. ;) so here are our options: * create a better view which does not replicate the problems of cascading menus or any of the other things the current view does improve on * live with it in either case, trying to peruade people with words is not useful in this particular situation because it is not words that are needed. cheers .. -- Aaron J. Seigo 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
On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin mgraess...@kde.org wrote: notethis is my last mail to this thread/note 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
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 mark...@gmail.com wrote: On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin mgraess...@kde.orgwrote: notethis is my last mail to this thread/note 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: Breadcrumbs in Kickoff
On Sat, Dec 31, 2011 at 12:46 PM, Marco Martin notm...@gmail.com wrote: On Saturday 31 December 2011, Martin Gräßlin wrote: 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. i think on the left is more sane It is also more consistent with other breadcrumb bars in KDE and other desktop environments. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
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. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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
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: Breadcrumbs in Kickoff
On Saturday 31 December 2011, Martin Gräßlin wrote: 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. i think on the left is more sane -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Breadcrumbs in Kickoff
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: Breadcrumbs in Kickoff
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: Re: Breadcrumbs in Kickoff
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: Breadcrumbs in Kickoff
On Tuesday 20 December 2011 17:54:02 Martin Gräßlin wrote: Up to now nobody gave a proper reason *why* we should add a back button. Just because we can is no reason, sorry. First, I understand that the back button is gone and I'm not advocating its return. I do think I understand why there is a backlash about this option, and it stems from two points: 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. 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. Based upon these two points, a couple of simple solutions present themselves: 1) Make the text a little bigger. Since users will approach the breadcrumbs from the bottom, increasing the height will help them hit the button easier. This will probably require some fiddling with to ensure the best possible result. 2) At least for LTR, move the breadcrumbs over to the left hand side. This will help users more easily find the breadcrumbs and choose an option. This also helps with selection, as any overshoot to return to the beginning, when approached from the right, will hit the edge of the screen and avoid too much backtracking, making it easier for users to hit. Note this only applies in Kickoff's default location, but I don't think most people will have an issue. Thoughts? If these ideas sound useful, I'll try to cook up a patch to implment them. Matthew [1] http://en.wikipedia.org/wiki/Fitts%27s_law ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
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 on the Mouse. (Less new code, less confusion, less maintenance headache.) That assumes that the mouse has such a nonstandard button in the first place. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
this is my last email on the matter as i refuse to allow decision by endless discussion and acceptable means of resolution have been put forward. On Wednesday, December 21, 2011 00:51:45 Alexey Chernov wrote: 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 know what you meant, and i'm saying that's not going to happen for the reasons already outlined. please respect that. I don't think it's perfect idea to fork kickoff because of one function. as Martin noted, this has a way of becoming 2 functions, then 3, then 4, then ... we've been there before with other software. we know how this works. you can promise me the moon and just one function but i _know_ that is not how it works in the long run. we've also experimented with create a different plasmoid. we did it first with clocks, we've done it with many others since, even including the tasks widget of which there are now ~4 different options out there that i'm aware of. and it works really, really well - people can find exactly the feature set they want, and don't have to put up with what they don't want. put another way, we don't end up with a tyranny of the minority. a few people want it to work a specific way, and the rest don't want the hassle and bother of having to wade through complex configuration. to meet everyone's needs, we create multiple widgets with the default one being the most applicable version (which, btw, can change over time) as a result of this approach, we have great new features in the default task widget and a ton of great features in the alternative offerings. it works. so rather than trying to struggle against the wishes of the people working on plasma day-in, day-out please consider simply trying the solution we're offering. 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. so let's not put it in just to take it out again later. or, hell, you could attempt the research you're talking about and come up with something _actually_ better rather than just going back to something not great and the breadcrumbs are more consistent with what we see elsewhere (file dialog, dolphin, ..) That's right. But there're areas (URL string in browser, date and time string in clock applications, rich text editors etc.) where breadcrumbs look more natural but in spite of it it's not used there. because they aren't navigable paths. Yes, it will probably make something more consistent but will spoil things in many other areas. I don't think consistency is the key factor here. it's a reason to select it as a solution. As to me, my solution is: keep both Back button and breadcrumbs. i don't think it makes sense to just add every possible idea and hope one of them works for people :) it will also look rather horrible :/ 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 but ... that's the definition of redundancy and duplication :) 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. trust me, this is not a significant number of comments. relative to other topics we've been through, this is a small number. moreover, it is impossible to simply respond to number of comments by doing whatever those comments suggest and get a coherent product. most commenters do not have the knowledge and experience necessary to offer proper advice, any more than i can suggest to a structural engineer how to build a bridge ... despite the fact that i've used thousands of bridges in my life and continue to use them every day. so while the amount of feedback is a useful metric (and in this case, it's not very high), and listening to what the _problem_ is is useful .. usually the suggested solution content is less useful. in this particular case, we purposefully decided against the back button. we will not be going back on that. any new adjustments should have user testing and consist of more than just put the old failed method back. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Breadcrumbs in Kickoff
Alexey made several valid points. It's not a question of whether or not to add a back button, it's a question of whether or not to restore it. If it's a question of redundancy, one might argue that the new breadcrumb navigation could be removed in favour of the classic back button. After all, most of the sub-categories are less than one level deep. As for the notion that most prominent KDE apps don't possess back buttons, there are actually quite a few examples, such as Konqueror/Rekonq, the System Settings application, and Dolphin. Dolphin arguably also has redundancy, as it possesses both breadcrumb navigation and a back button. If both Aaron and Martin claim to want consistency, why are they going against the paradigms implemented in Dolphin, namely BOTH the back button and breadcrumb navigation. (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). Martin, how can you claim to care about the opinions of KDE's userbase, when you refuse to consider the possiblity that many of KDE's users may want this feature? Why would you make it read-only if you care about the community's opinion? You don't have any statistics invalidating my statements. Have KDE users requested the removal of the back button? No. Have KDE users requested the reinstatement of the back button? Yes. Do we care about KDE's users? Yes. So, why are we removing a feature? A feature that few, perhaps none of the users have complained about. The fact that any users made the effort to not only register to the issue tracker, but also find the specific issue and post to it, demonstrates that, in fact, more users want the back button, than those that would ask for its removal. In fact, it should be obvious that users care about the back button, given that I, a mere user, have spent close to 2 months pursuing this issue, and, consequently, have joined this mailing list. In the past, have you encountered such ire? Such dedication to a single feature? 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 Sythe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On 20 дек 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 on 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 (for 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 easy 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
Xavier, while I also want the back button back, it seems to me that you miss several important points: As for the notion that most prominent KDE apps don't possess back buttons, there are actually quite a few examples, such as Konqueror/Rekonq, the System Settings application, and Dolphin. There are very few cases with a back button like the one in Kickoff (I can only think of QuickAccess). Personally I think it could have a place in more widgets though. Dolphin arguably also has redundancy, as it possesses both breadcrumb navigation and a back button. As previously explained, the back button in Dolphin doesn't serve the same purpose as the breadcrumbs. Redundancy would be to have both the breadcrumbs and the Up button by default, which it doesn't have. Martin, how can you claim to care about the opinions of KDE's userbase, when you refuse to consider the possiblity that many of KDE's users may want this feature? I think you missed the try to rally part. Why would you make it read-only if you care about the community's opinion? The navigation in Kickoff has received many complaints since it was introduced. People found it slow to navigate, couldn't see which level they were at etc. Breadcrumbs solve some of these issues. In fact, it should be obvious that users care about the back button, given that I, a mere user, have spent close to 2 months pursuing this issue, and, consequently, have joined this mailing list. In the past, have you encountered such ire? Such dedication to a single feature? One example doesn't say very much. I'm sure you can find more than one dedicated user who wants the classic menu to be the default, but that doesn't mean that it should be. In short: It seems clear that the developers aren't interested in adding the back button back. Therefore I suggest that we follow their suggestion, i.e., someone creating an alternative Kickoff with the back button (having it as an additional option is just silly in my opinion). If it becomes very popular, the developers might reconsider. Or not. I also suggest that someone tries to find the original usability study performed by openSUSE(?) when creating Kickoff. If I remember correctly the back button, being on the left edge where it's easy to hit, was one of the important parts of the application launcher. Maybe we could get an opinion from one of the usability experts involved with the original concept. As for me, I personally don't use Kickoff much, so I don't care enough to spend any significant time on the issue. But as said I would prefer a back button. Hans On Wed, Dec 21, 2011 at 17:59, Xavier Sythe m...@sythe.me wrote: Alexey made several valid points. It's not a question of whether or not to add a back button, it's a question of whether or not to restore it. If it's a question of redundancy, one might argue that the new breadcrumb navigation could be removed in favour of the classic back button. After all, most of the sub-categories are less than one level deep. As for the notion that most prominent KDE apps don't possess back buttons, there are actually quite a few examples, such as Konqueror/Rekonq, the System Settings application, and Dolphin. Dolphin arguably also has redundancy, as it possesses both breadcrumb navigation and a back button. If both Aaron and Martin claim to want consistency, why are they going against the paradigms implemented in Dolphin, namely BOTH the back button and breadcrumb navigation. (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). Martin, how can you claim to care about the opinions of KDE's userbase, when you refuse to consider the possiblity that many of KDE's users may want this feature? Why would you make it read-only if you care about the community's opinion? You don't have any statistics invalidating my statements. Have KDE users requested the removal of the back button? No. Have KDE users requested the reinstatement of the back button? Yes. Do we care about KDE's users? Yes. So, why are we removing a feature? A feature that few, perhaps none of the users have complained about. The fact that any users made the effort to not only register to the issue tracker, but also find the specific issue and post to it, demonstrates that, in fact, more users want the back button, than those that would ask for its removal. In fact, it should be obvious that users care about the back button, given that I, a mere user, have spent close to 2 months pursuing this issue, and, consequently, have joined this mailing list. In the past, have you encountered such ire? Such dedication to a single feature? 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 Sythe
Re: Breadcrumbs in Kickoff
On Wed, Dec 21, 2011 at 21:07, Alexey Chernov 4er...@gmail.com wrote: On 20 дек 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 on 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 (for 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 easy 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Breadcrumbs in Kickoff
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
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: Breadcrumbs in Kickoff
On 21 дек 2011 08:25:03 Martin Gräßlin wrote:
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.
As I said before, I agree with it. I don't know the whole background but it
seems to be right.
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.
Yes, we discuss it as you propose it as the only way with the Back button.
Now you give an argument that config options are bad in general. Does it mean
it never was an option?
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.
Nope, I'm not. But since you mentioned millions of users somewhere below I
would expect some usability research to be performed for such kind of cases.
So my question is: how then it was decided that Back button should be replaced
with breadcrumbs? Is it right that you don't know whether it's better or worse
than Back button in terms of usability but still make such a decision?
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.
I meant application main menu (File, Edit, View etc.), sorry if it wasn't
expressed clear. Also I wouldn't say Unity is an ideal example for this, but
AFAIK it just moves application main menu to global level so main menu isn't
gone completely. Anyway, it was example that multiple ways to the same
functionality aren't necessary evil, redundancy or duplication, it was just a
description for my argument ('no redundancy or duplication').
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 ;-)
No, not really, I initially wanted to keep both methods, you can see it in my
bug report (http://bugs.kde.org/show_bug.cgi?id=285401) which is now a
duplicate to more famous one. We just began to discuss a config option but
Aaron and you pointed to the problems with config and I tend to agree.
- 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 %.
Hmm.. OK.
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.
Well, it depends. For someone every single user is significant, other projects
can lose thousands of users and feel good. For me it seems significant.
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.
Re: Breadcrumbs in Kickoff
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 :). i do not want plasma desktop to become a collection of everyone's pet features with a thousand configuration tweaks. the back button was not serving everyone well (we got lots of feedback on it ...) and the breadcrumbs are more consistent with what we see elsewhere (file dialog, dolphin, ..) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Breadcrumbs in Kickoff
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. 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. 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. and the breadcrumbs are more consistent with what we see elsewhere (file dialog, dolphin, ..) That's right. But there're areas (URL string in browser, date and time string in clock applications, rich text editors etc.) where breadcrumbs look more natural but in spite of it it's not used there. Yes, it will probably make something more consistent but will spoil things in many other areas. I don't think consistency is the key factor here. 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) - minimum of code required 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On 01/-10/-28163 11:59 AM, Alexey Chernov wrote: 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) - minimum of code required 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. 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 on 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Breadcrumbs in Kickoff
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 election the state is governed by a prime minister of the
Re: Re: Re: Re: Breadcrumbs in Kickoff
On 01/-10/-28163 11:59 AM, Martin Grlin 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: Breadcrumbs in Kickoff
I'll answer to Martin Gräßlin to move discussion from the certain bug report (http://bugs.kde.org/show_bug.cgi?id=274489) here to keep the whole discussion in one place. Very interesting discussion in plasma-devel but I personally didn't find any arguments why the 'Back' button is bad but something like We decided to remove this button and would never revert it. Period. Being bluntly: The option to revert does not exist. We changed to breadcrumbs in 4.7, 4.8 is going to be tagged as RC tomorrow, so it is impossible to do any changes and reverting in 4.9 is clearly no option any more. Too many users got used to the new style, so what do we gain by breaking the workflow? Well, why then you came to decision to remove Back button after 4.6? :) Didn't it break the workflow? Or users who prefer to use Back button is somehow worse or less important than those who prefer breadcrumbs? So we do not need to discuss whether the back button is bad. The only thing which can be discussed is whether the back button is so important that it needs a config option and that it is worth the amount of work to add and more important to maintain it. OK, let's discuss the config option which is I think would satisfy most of us. For me there has not been any convincing argument that it needs an option which means that currently I will not add it and would not even accept a patch. You asked for usability studies to prove some arguments before in this thread and here you state as if it's you to decide what will be accepted and what won't be accepted. So it's unclear whether there was some usability research result that breadcrumbs are better than Back button or it was just decided by someone and implemented. But I personally don't see any danger in both elements together. 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. Please keep discussions to one place and that's the mailing list thread. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
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). Implementing this, Xavier (and others) would be able to buy and use a mouse with Thumb buttons, back and forward, and just whack the 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. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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
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.) / too much information 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: Re: Breadcrumbs in Kickoff
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
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 mgraess...@kde.org 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 merged into master [1] http://blog.martin-graesslin.com/blog/2011/12/experience-from-porting-
Re: Re: Breadcrumbs in Kickoff
Hi, I don't have any strong opinions to either solution, but I just want to state my views on this discussion. snip 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
On Sat, Dec 17, 2011 at 17:02, Martin Klapetek martin.klape...@gmail.comwrote: 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
On Sat, Dec 17, 2011 at 4:18 PM, Martin Gräßlin mgraess...@kde.org 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
On Sat, Dec 17, 2011 at 5:02 PM, Martin Klapetek martin.klape...@gmail.com 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
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 Grlin mgraess...@kde.org 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
Re: Breadcrumbs in Kickoff
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 merged into master [1] http://blog.martin-graesslin.com/blog/2011/12/experience-from-porting- kickoff-to-qml/ 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: Breadcrumbs in Kickoff
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 mgraess...@kde.org 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 merged into master [1] http://blog.martin-graesslin.com/blog/2011/12/experience-from-porting- kickoff-to-qml/http://blog.martin-graesslin.com/blog/2011/12/experience-from-porting-%0Akickoff-to-qml/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
