Re: Add multiple feeds to rssnow (Qml) plasmoid
On Saturday 17 December 2011, Antonis Tsiapaliokas wrote: > Hello > > I am creating a patch, for adding multiple feeds to rssnow (Qml) plasmoid, > but i have stuck and i need some help. > The c++ plasmoid is using signals and custom slots to add/remove feeds from > the plasmoid. > And here is where i stuck. How exactly can i add a custom "slot" to the > rssnow (Qml) plasmoid without using c++? > to be able to have multiple feeds, just do the right things in the configurationChanged() function (in javascript, main qml file) to have slots, just implement an onSignal: function or if you need to connect to a signal from another item, use the Connections item: http://developer.qt.nokia.com/doc/qt-4.8/qml-connections.html Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
qtcomponents documentation
Hi all, I think we should do a real documentation sprint for the plasma qtcomponents, to have a good api doc for the 4.8 release. I have now merged the branch plasma-components-doc as the documentation was already good (and avoiding conflicts with master) I have to say congratulations to who woked on it, let's complete and make it rock for 4.8 ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: problem with icontask and javascript
Ty Ty i did ;( i had not seen that on kde wiki :( blind man 2011/12/16 Aaron J. Seigo > On Friday, December 16, 2011 07:29:45 Nowardev-Team wrote: > > var icontasks = panel.addWidget("icontasks") > > icontasks.writeConfig("groupClick","1") > > icontasks.writeConfig("unity","true") > > //icontasks.writeConfig("Enabled","true") > > > > > icontasks.writeConfig("Items","file:///usr/share/applications/firefox.deskto > > > p?wmClass=Firefox,file:///usr/share/applications/kde4/kate.desktop?wmClass=K > > > ate,file:///usr/share/applications/kde4/konversation.desktop?wmClass=Konvers > > > ation,file:usr/share/applications/kde4/dolphin.desktop?wmClass=Dolphin,f > > > ile:///usr/share/applications/chromium-browser.desktop?wmClass=Chromium-brow > > > ser,file:///usr/share/applications/kde4/konsole.desktop?wmClass=Konsole,file > > > :///usr/share/applications/kde4/ksnapshot.desktop?wmClass=Ksnapshot,file:/// > > > usr/share/applications/kde4/systemsettings.desktop?wmClass=Systemsettings") > > > *I'm not 100% sure, by Launchers are in a different group.* > > from > http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting > > Array[String] currentConfigGroup: > > the current configuration group path, with each entry in the array > representing > a sub-group. This allows one to access trees of groups with code such as: > widget.currentConfigGroup = new Array('topGroup', 'subGroupOfTopGroup'). An > empty Array means the default (top-level) configuration group for the > widget > > > so you probably want sth like: > > icontasks.currentConfigGroup = new Array('Launchers') > icontasks.writeConfig("Items", "") > > -- > 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 > > ___ > 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
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
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. > > 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 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
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
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: qtcomponents documentation
On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > Hi all, > > I think we should do a real documentation sprint for the plasma > qtcomponents, to have a good api doc for the 4.8 release. and ideas / preferences on when and where? -- 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: qtcomponents documentation
On Saturday 17 December 2011, Aaron J. Seigo wrote: > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > Hi all, > > > > I think we should do a real documentation sprint for the plasma > > qtcomponents, to have a good api doc for the 4.8 release. > > and ideas / preferences on when and where? well, was actually more thinking about an irc meeting, kinda like bugdays, next week (or after the christmasy things if better for people) to get all documented and at least a tutorial with pretty pictures on the wiki -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qtcomponents documentation
That's fine for me. Marco, I'm still working on the branch, should I submit the changes into it or directly in master? Cheers, On Saturday, December 17, 2011 02:11:06 PM Marco Martin wrote: > On Saturday 17 December 2011, Aaron J. Seigo wrote: > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > > Hi all, > > > > > > I think we should do a real documentation sprint for the plasma > > > qtcomponents, to have a good api doc for the 4.8 release. > > > > and ideas / preferences on when and where? > > well, was actually more thinking about an irc meeting, kinda like bugdays, > next week (or after the christmasy things if better for people) > > to get all documented and at least a tutorial with pretty pictures on the > wiki -- Daker Fernandes Pinheiro openBossa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qtcomponents documentation
On Saturday, December 17, 2011 18:11:06 Marco Martin wrote: > On Saturday 17 December 2011, Aaron J. Seigo wrote: > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > > Hi all, > > > > > > I think we should do a real documentation sprint for the plasma > > > qtcomponents, to have a good api doc for the 4.8 release. > > > > and ideas / preferences on when and where? > > well, was actually more thinking about an irc meeting, kinda like bugdays, > next week (or after the christmasy things if better for people) perhaps set up a doodle for people to register their preferred times and then we can promote it on our blogs? -- 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: qtcomponents documentation
Sounds like a good plan. Daker Fernandes Pinheiro 2011/12/17 Aaron J. Seigo > On Saturday, December 17, 2011 18:11:06 Marco Martin wrote: > > On Saturday 17 December 2011, Aaron J. Seigo wrote: > > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > > > Hi all, > > > > > > > > I think we should do a real documentation sprint for the plasma > > > > qtcomponents, to have a good api doc for the 4.8 release. > > > > > > and ideas / preferences on when and where? > > > > well, was actually more thinking about an irc meeting, kinda like > bugdays, > > next week (or after the christmasy things if better for people) > > perhaps set up a doodle for people to register their preferred times and > then > we can promote it on our blogs? > > -- > 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 > > ___ > 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: Review Request: Activities Dataengine: avoid calling KActivities::Controller::listActivities() unnecessarily
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103358/#review9027 --- This review has been submitted with commit 480db607b4ec63108e18738eb2dfa51169dcd865 by Luiz Romário Santana Rios to branch master. - Commit Hook On Dec. 16, 2011, 12:25 a.m., Romário Rios wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103358/ > --- > > (Updated Dec. 16, 2011, 12:25 a.m.) > > > Review request for Plasma. > > > Description > --- > > Avoid calling listActivities to get the list of running activities everytime > by getting it once, storing it in a private member and modifying this member > as activities come and go. > > > Diffs > - > > plasma/generic/dataengines/activities/activityengine.h cbbf94c > plasma/generic/dataengines/activities/activityengine.cpp 9436c34 > > Diff: http://git.reviewboard.kde.org/r/103358/diff/diff > > > Testing > --- > > Tested it now, removed some activities, added some more, stopped another > bunch, and it seems to work just fine as long as I tested. > > > Thanks, > > Romário Rios > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: qtcomponents documentation
Le samedi 17 décembre 2011 15:52:33 Daker Fernandes Pinheiro a écrit : > Sounds like a good plan. > > Daker Fernandes Pinheiro > > > > 2011/12/17 Aaron J. Seigo > > > On Saturday, December 17, 2011 18:11:06 Marco Martin wrote: > > > On Saturday 17 December 2011, Aaron J. Seigo wrote: > > > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > > > > Hi all, > > > > > > > > > > I think we should do a real documentation sprint for the plasma > > > > > qtcomponents, to have a good api doc for the 4.8 release. > > > > > > > > and ideas / preferences on when and where? > > > > > > well, was actually more thinking about an irc meeting, kinda like > > bugdays, > > > next week (or after the christmasy things if better for people) > > > > perhaps set up a doodle for people to register their preferred times and > > then > > we can promote it on our blogs? Not sure whether I'll be able to help, but for what it's worth, I've started using these components in the skrooge plasma dashboard. So far, I've made progresses using source code, Daker's gallery, and his help on IRC. Having doc on this would be extremely helpful :) > > > > -- > > 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 > > > > ___ > > 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: Review Request: RSSNOW QML:reset the timer on click and some coding style fixes.
> On Dec. 16, 2011, 3:25 p.m., Aaron J. Seigo wrote: > > try using inkscape rather than carbon for the svg changes. it worked!!(no issues) Because i can't create a diff of the removed files here, diff --git a/applets/rssnow/CMakeLists.txt b/applets/rssnow/CMakeLists.txt index 5762dbf..72be160 100644 --- a/applets/rssnow/CMakeLists.txt +++ b/applets/rssnow/CMakeLists.txt @@ -15,8 +15,7 @@ install(TARGETS plasma_applet_rssnow DESTINATION ${PLUGIN_INSTALL_DIR}) install(FILES plasma-applet-rssnow.desktop DESTINATION ${SERVICES_INSTALL_DIR}) install(FILES feeds DESTINATION ${DATA_INSTALL_DIR}/rssnow) install(FILES -left.svgz -right.svgz +arrows.svgz rssnow.svgz background.svgz DESTINATION ${DATA_INSTALL_DIR}/desktoptheme/default/rssnow/) diff --git a/applets/rssnow/left.svgz b/applets/rssnow/left.svgz deleted file mode 100644 index ca03cd3..000 Binary files a/applets/rssnow/left.svgz and /dev/null differ diff --git a/applets/rssnow/right.svgz b/applets/rssnow/right.svgz deleted file mode 100644 index c3c2285..000 Binary files a/applets/rssnow/right.svgz and /dev/null differ $ git status # On branch master # Changes not staged for commit: # (use "git add/rm ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: applets/rssnow/CMakeLists.txt # deleted:applets/rssnow/left.svgz # deleted:applets/rssnow/right.svgz i know it is lame.. should i push? - Giorgos --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103347/#review9007 --- On Dec. 16, 2011, 12:12 p.m., Giorgos Tsiapaliwkas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103347/ > --- > > (Updated Dec. 16, 2011, 12:12 p.m.) > > > Review request for Plasma. > > > Description > --- > > Hello, > > the Timer component will reset to zero when the user clicks the arrows. > Also i made some fixes in the coding style. > > thanks in advance > > > Diffs > - > > rssnow/package/contents/ui/ListItemEntry.qml dac3f93 > rssnow/package/contents/ui/main.qml e39a1f6 > > Diff: http://git.reviewboard.kde.org/r/103347/diff/diff > > > Testing > --- > > everything is ok > > > Thanks, > > Giorgos Tsiapaliwkas > > ___ 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 Gräßlinwrote: 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
QML Activity List
Hello, list. So, some time ago I started to try creating a list of the activities in QML, using the org.kde.activities data engine. I achieved something, but I had some problems and my idea was to make it a PopupApplet, but it was broken in QML - and even in JS, I guess - at the time. I tried to workaround it, but the result was rather ugly. Some problems follow: 1 - As it's a regular applet trying to mimic a PopupApplet, it seems out of place, as it occupies a bit more space than the needed for the icon. 2 - The popup list with the activities appears anywhere except above the icon. 3 - The same popup list makes an entry in the taskbar. 4 - If I try to filter the sources in any way to show only the activities, the list becomes empty; if I don't, a ghost entry, corresponding to the source "Status", appears in the list. 5 - I don't know how to use the plasma style in the list, so the items are ugly grey squares. 6 - I made the hover and click events change the colors of the items in the list, to give them some hover effect, but the colors don't change. Anyway, it's been some time now that I made this applet, and I think I should be using the Components by now, but I don't know where to start or what to change in my applet and what is done wrong and right in it. I don't know if I can send attachments to the list, so, since it's a really small applet, I'm sending it via paste: / - metadata.desktop: http://paste.kde.org/175196/ - contents/ -- qml/ --- main.qml: http://paste.kde.org/175208/ (That's the directory tree) Any help would be appreciated. -- Luiz Romário Santana Rios ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel