Re: Review Request: Save scrollbar position on plasma exit
> On March 13, 2012, 1:12 p.m., Marco Martin wrote: > > looks good, a thing i would like to be tested is when the saved position is > > invalid, like either negative or an enormous value. > > > > this shouldn't break it (is even quite probable a value not being valid > > anymore because there are less files than the previous session) > > Fredrik Höglund wrote: > I think it would be a good idea to save the modification time for the > folder and use that to check if the saved scrollbar value is likely to be > invalid. If the user is able to scroll the view while the layout is in > progress, this should also abort restoring the position. > > Also, I'm wondering if we really need to save the position separately for > the iconview and the listview, or if we should use the same key. > > Otherwise the patch looks good to me. > > Ignat Semenov wrote: > Well I've been thinking about separate vs single key and I think separate > is easier to read and maintain, less checks and branches. > > The main problem with a single key would be when the applet is put into a > panel, first the icon view gets created and grabs the value, then the list > view gets created and gets a 0. Two keys are easier to work with I think. > > As for scrolling when the layout is in progress, this method is intended > to be used at startup only, so the user can not scroll the view. Or do you > mean that some dev could use restoreScrollbarPosition() manually after > startup? > > Folder mtime is a nice idea, one more corner case, will try to implement. > > Ignat Semenov wrote: > Actually, aborting the automatic scrolling works just fine, as > smoothScroll(savedPosition) is used and that one can be interrupted easily. > > Ignat Semenov wrote: > OK, as discussed with fredrikh on IRC yesterday, the patch now accounts > for multiple layout passes. > As far as the dir mtime issue goes, I think that actually falls into the > range check case, that is, if the dir content changes, but the number of rows > does not, it's probably ok to restore the scroll position. If the number of > rows changes, then the scrollbar range changes and that is caught by the > check in scrollToSavedPosition(). Same for the list view. > > Now the only relevant issue is actually aborting the restore if scrolling > the view between layout passes in a slow dir. OK, the only thing left now is to correctly handle this: applet created on the desktop -> scrolled -> put into the panel ->url changed -> dragged back to the desktop -> scrolled again, but the dir is different and the scroll is invalid on the other hand, we can't simply discard the value after restoring the position, since if the above is done without changing the url, the scrollbar restore on panel -> desktop is desired and correct. - Ignat --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104258/#review11354 --- On March 16, 2012, 4:31 p.m., Ignat Semenov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104258/ > --- > > (Updated March 16, 2012, 4:31 p.m.) > > > Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. > > > Description > --- > > This patch implements scrolbar position saving on plasma exit. The change is > fairly trivial, however, due to the fact that the view is not populated and > layouted immediately simply scrolling to the desired position on creating the > view does not work. Instead a signal is emitted on finishing the item layout, > when the view has a valid size and the scrollbar has a valid range. The > signal is connected to a slot which scrolls the view to the desired position > and then disconnects the signal. For the user, a public function in > AbstractItemView is introduced, which performs the connection. > > The only problem is that ListView turned out not to have any layout method. > It just paints the items one by one, calculating their position on the fly, > so I put the signal at the end of updateScrollbar to ensure the scrollbar > range is valid. Maybe it should go into the "if (max>0)" branch? > > > This addresses bug 261139. > http://bugs.kde.org/show_bug.cgi?id=261139 > > > Diffs > - > > plasma/applets/folderview/abstractitemview.h aa68b90 > plasma/applets/folderview/abstractitemview.cpp 3debb70 > plasma/applets/folderview/folderview.h 4e441eb > plasma/applets/folderview/folderview.cpp a94ce87 > plasma/applets/folderview/iconview.h 12e93b3 > plasma/applets/folderview/iconview.cpp 5c4e086 > plasma/applets/folderview/listview.cpp 94efe44 > > Diff: http://git.reviewboa
Review Request: do not crash when passing a url in the ctor e.g. when creating a folderview by dropping a folder onto the desktop
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104311/ --- Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Description --- Do not call setUrl in the ctor since m_dirLister does not exist yet. Instead, assign m_url in the ctor and call setUrl later in init(). Diffs - plasma/applets/folderview/folderview.cpp a94ce87 Diff: http://git.reviewboard.kde.org/r/104311/diff/ Testing --- Tested, works. Would be nice to give the code a static analyzer run, if there was a decent static analyzer available in Linux. Anybody have relevant experience? Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: do not crash when passing a url in the ctor e.g. when creating a folderview by dropping a folder onto the desktop
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104311/ --- (Updated March 17, 2012, 9:52 a.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Description --- Do not call setUrl in the ctor since m_dirLister does not exist yet. Instead, assign m_url in the ctor and call setUrl later in init(). Diffs - plasma/applets/folderview/folderview.cpp a94ce87 Diff: http://git.reviewboard.kde.org/r/104311/diff/ Testing --- Tested, works. Would be nice to give the code a static analyzer run, if there was a decent static analyzer available in Linux. Anybody have relevant experience? Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: do not crash when passing a url in the ctor e.g. when creating a folderview by dropping a folder onto the desktop
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104311/ --- (Updated March 17, 2012, 9:52 a.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Description --- Do not call setUrl in the ctor since m_dirLister does not exist yet. Instead, assign m_url in the ctor and call setUrl later in init(). Diffs - plasma/applets/folderview/folderview.cpp a94ce87 Diff: http://git.reviewboard.kde.org/r/104311/diff/ Testing --- Tested, works. Would be nice to give the code a static analyzer run, if there was a decent static analyzer available in Linux. Anybody have relevant experience? Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Remember current desktop when changing activity
> On March 16, 2012, 12:49 p.m., Ivan Čukić wrote: > > > > makis marimpis wrote: > Hm, i did that in order to restore the desktop ids from a previous run of > kamd (let's say, in case of log out). You misunderstood, I don't mind saving it in the config file, I don't understand the need to keep all those in memory. For example, Bob has 20 activities, usually uses only 3 of them. Why would you want to keep the rest of the VD IDs in memory? Just read the VD ID when necessary. As you can see, we are not keeping anything that is saved to a config file in memory apart from the list of activities. The names, icons etc. are read from the config when needed. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/#review11467 --- On March 16, 2012, 11:55 a.m., makis marimpis wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104261/ > --- > > (Updated March 16, 2012, 11:55 a.m.) > > > Review request for KDE Runtime and Plasma. > > > Description > --- > > Patches kactivitymanagerd to store (and restore back) the working current > directory when switching activities. > > The activity-changing-behavior is as follows: > 1. Say you have two (or more activities) A and B. > 2. You are working on activity A on Desktop 4. > 3. You switch to activity B (and by default to Desktop 4). > 4. Change to Desktop 1. > 5. Go back to activity A and (by default) to Desktop 1, while it should move > you to Desktop 4 (this is where my patch kicks in). > > I hope it makes sense :-) > > > This addresses bugs 241864 and 265015. > http://bugs.kde.org/show_bug.cgi?id=241864 > http://bugs.kde.org/show_bug.cgi?id=265015 > > > Diffs > - > > service/ActivityManager.cpp 7af2049 > service/ActivityManager_p.h d054eb7 > > Diff: http://git.reviewboard.kde.org/r/104261/diff/ > > > Testing > --- > > > Thanks, > > makis marimpis > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: do not crash when passing a url in the ctor e.g. when creating a folderview by dropping a folder onto the desktop
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104311/#review11504 --- Ship it! Ship It! - Fredrik Höglund On March 17, 2012, 9:52 a.m., Ignat Semenov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104311/ > --- > > (Updated March 17, 2012, 9:52 a.m.) > > > Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. > > > Description > --- > > Do not call setUrl in the ctor since m_dirLister does not exist yet. Instead, > assign m_url in the ctor and call setUrl later in init(). > > > Diffs > - > > plasma/applets/folderview/folderview.cpp a94ce87 > > Diff: http://git.reviewboard.kde.org/r/104311/diff/ > > > Testing > --- > > Tested, works. > > Would be nice to give the code a static analyzer run, if there was a decent > static analyzer available in Linux. Anybody have relevant experience? > > > Thanks, > > Ignat Semenov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
2012/3/15 Martin Gräßlin : > Hi all, > > in order to find a better name for the window decoration "Laptop" I created a > doodle with possible names: > > http://www.doodle.com/e9se6zuz8ufepxke > > More info: https://git.reviewboard.kde.org/r/104282/ > > Please vote for your preferred name and don't make the fun out of it that > everybody votes for a different name ;-) Hm. Just an idea, but does the new name really have to be descriptive like that? Couldn't we go for a name like "Hydrogen" (a simpler atom than oxygen)? The fact that this decoration is more suitable for remote desktops could perhaps be conveyed some other way than through the name? (a description shown in the KCM perhaps?). If it needs to be conveyed in words at all.. perhaps it's enough to see the preview.. By going with a descriptive name I think we'll always end up with something that could put Oxygen in a bad light. Cheers, Elvis > > Cheers > Martin > ___ > 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: Remember current desktop when changing activity
> On March 16, 2012, 12:49 p.m., Ivan Čukić wrote: > > > > makis marimpis wrote: > Hm, i did that in order to restore the desktop ids from a previous run of > kamd (let's say, in case of log out). > > Ivan Čukić wrote: > You misunderstood, I don't mind saving it in the config file, I don't > understand the need to keep all those in memory. > > For example, Bob has 20 activities, usually uses only 3 of them. Why > would you want to keep the rest of the VD IDs in memory? > > Just read the VD ID when necessary. > > As you can see, we are not keeping anything that is saved to a config > file in memory apart from the list of activities. The names, icons etc. are > read from the config when needed. Now i see your point. I have implemented the same patch using only KConfigGroup but because of the "scheduleConfigSync" there is a case where the sync cannot keep up with the change of the activities - leading to a weird behavior (the changes are not yet made volatile). That could be solved by calling "configSync" explicitly but that could affect the performace? (no idea). To sum up: i think it is faster and less error-prone to store in memory and sync whenever sync is scheduled to, than to read/write whenever an activity is changed. - makis --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/#review11467 --- On March 16, 2012, 11:55 a.m., makis marimpis wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104261/ > --- > > (Updated March 16, 2012, 11:55 a.m.) > > > Review request for KDE Runtime and Plasma. > > > Description > --- > > Patches kactivitymanagerd to store (and restore back) the working current > directory when switching activities. > > The activity-changing-behavior is as follows: > 1. Say you have two (or more activities) A and B. > 2. You are working on activity A on Desktop 4. > 3. You switch to activity B (and by default to Desktop 4). > 4. Change to Desktop 1. > 5. Go back to activity A and (by default) to Desktop 1, while it should move > you to Desktop 4 (this is where my patch kicks in). > > I hope it makes sense :-) > > > This addresses bugs 241864 and 265015. > http://bugs.kde.org/show_bug.cgi?id=241864 > http://bugs.kde.org/show_bug.cgi?id=265015 > > > Diffs > - > > service/ActivityManager.cpp 7af2049 > service/ActivityManager_p.h d054eb7 > > Diff: http://git.reviewboard.kde.org/r/104261/diff/ > > > Testing > --- > > > Thanks, > > makis marimpis > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
for use on remote desktops? "remote" for use on a slower connection? "sublight" for good compression ratios? "compressed", "condensed" cigarette and beer companies had to change "light" to something else... "bold", "distinct" ... On Sat, Mar 17, 2012 at 11:38 AM, Elvis Stansvik wrote: > 2012/3/15 Martin Gräßlin : >> Hi all, >> >> in order to find a better name for the window decoration "Laptop" I created a >> doodle with possible names: >> >> http://www.doodle.com/e9se6zuz8ufepxke >> >> More info: https://git.reviewboard.kde.org/r/104282/ >> >> Please vote for your preferred name and don't make the fun out of it that >> everybody votes for a different name ;-) > > Hm. Just an idea, but does the new name really have to be descriptive > like that? Couldn't we go for a name like "Hydrogen" (a simpler atom > than oxygen)? > > The fact that this decoration is more suitable for remote desktops > could perhaps be conveyed some other way than through the name? (a > description shown in the KCM perhaps?). If it needs to be conveyed in > words at all.. perhaps it's enough to see the preview.. > > By going with a descriptive name I think we'll always end up with > something that could put Oxygen in a bad light. > > Cheers, > Elvis > >> >> Cheers >> Martin >> ___ >> 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
QML Plasmoids and complex configs
I've been given the impression that all plasmoids are moving to QML, and as such I'm trying to make sure that happens in my project, KDE Telepathy. >From my understanding QML plugins can only use configs by shipping a .ui file, and the XML config file. This doesn't really cut our needs in one of our configs. We have a config (in contact-applet) that shows a tree view of available contacts. This is far beyond what I can do in just QtDesigner and I currently need my C++ applet to do this. Are C++ applets being phased out? Will there be a way to use QtScript in the config? Are the config dialogs going to be moved to QML? None of the above? I /can/ work round this by making a widget that has everything I want with the relevant user q_property and then making a QtDesigner plugin which exposes this widget so that Qt::UiLoader can load it. (I use this approach in LightDM-KDE which has a very similar config mechanism to plasma applets). However if lots of people do it, it will get very messy with libraries going everywhere. However, I felt it's something that's probably going to come up when porting a lot of applets, such as pastebin or the comics plasmoid, both of these load models in their config UIs, so will have the same problems. Side note, for someone who's developing a lot of stuff /on/ Plasma but not really involved /in/ Plasma there's not a lot of public communication about the general roadmap of Plasma2. On techbase there's simply a line that says "This is now the recommended method of creating plasmoids," on the QML section but you would actually miss if you click on any of the links to any of the other languages. I have to pick up most my information from hearsay/developer conversations and then fill the rest in with guesses. I'm not trying to rant, and possibly I'm looking in the wrong places, but if I'm struggling to find an official word of "this is how you should be writing plasmoids that will work 2 years from now", so will lots of people - and that's something that needs to be addressed, even if only in a blog post. David Edmundson. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
Alexander Neundorf wrote: > On Friday 16 March 2012, Kevin Ottens wrote: >> Hello, >> >> On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote: >> > [...] >> > this is what really piques my interest: merge based workflow. >> > >> > an integration branch would be fantastic. that branch should rebase >> > periodically off of master and only be used to merge feature branches. >> > this branch would largely take the place of current master: where >> > development "happens". feature branches should be merged into >> > integration on a regular basis and developers and testers should track >> > this integration branch in their day-to-day usage >> > >> > integration should always be open to feature branch merging. master >> > should only be open for feature merge when not in freeze, however. >> > >> > when in freeze, either a stabilization branch could be made off of >> > master for this purpose (probably a very good idea for larger fixes) >> > which is then merged down in master at known good points .. or .. >> > master is opened for bug fixes directly in those periods. the latter is >> > probably not as "good" from a stability POV, but may be more reasonable >> > and less of a workload for people doing the actual work. >> > >> > so what i'm interested in hearing is what sort of branch management >> > scheme would work for people. i'm happy to maintain either an >> > integration or the master branch (but not both). >> > [...] >> > >> > note that the methods being (slowly) adopted for frameworks devel are >> > also moving in the direction noted above. >> >> I'd just like to add my 0.02€ here. >> >> I've been thinking about the git workflow to be used in KDE Frameworks in >> the future. Based on observations and discussions with current and future >> frameworks maintainer, I think that it would be a mistake to force a >> single workflow for all the frameworks. I'm not 100% sure what the final >> solution will be but it's likely to end up being a short list of blessed >> workflows: 1) Full game, one branch per feature with review time in an >> integration/testing branch before hitting master; >> 2) Intermediate, one branch per feature with merge in master after >> reviewers/maintainer validation; >> 3) Easy, features directly developped in master[1]. > > Sounds good. > But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE > SC) would be also a really good thing to have. It will make contributing > easier. Would 2) be an option for KDE frameworks ? > :/ Am I the only person who values browsable history? Repositories where you can run gitk and see something useful. What Aaron proposed is exactly what CMake does. The result is that if you run gitk, you can't see the actual patches. If you run gitk --first-parent on master you *only* see merges, so the only information you can see is the name of the branch that got merged (which is in the git commit message), not the actual patch, and to see the patches in a topic you have to know the name of the topic. You can't just browse the commits, so you can't practically do post-commit review with gitk, as I do. Using email for that really doesn't work for me for one thing. If I want to look at commits that I vaguely know exist but I don't know which topic branch it came from, I should be able to browse fot that. I have the git repo in front of me, so I should be able to use it without jumping through too many hoops. We're going to have small repos after splitting, not large ones. Having a branch and a merge per patch commit in small repos is way overkill. Let's have readable history instead please. My vote is for 3 (for frameworks in general at least), and if people want to create branches like the actions or colors ones we currently have, lets do that in scratch or personal repos. They can be rebased/squashed to readable patches when the learning about how to create a framework by a contributor is done (that's not useful history). The actions branch should all be squashed into one commit because originally the contributor didn't realize the steps that are needed to make a split (move the files, update some include_directories, give the new framework a name which doesn't have kdeui in it, rename the deprecated and export macros). Currently none of those commits actually build because they don't do all of the necessary steps and even the tip of the branch isn't complete because the export macros haven't been changed. Once the branch is fixed to build, I will squash and rebase it to origin/frameworks to commit. The colors branch also contains lots of commits with typos, fixes for typos, adding missing files, removing stuff from CMake files which should have been removed in previous commits, etc, so I will also fix/squash/rebase that one when it's ready, but likely into more commits. Note that I say I'll do the rebase. I'm not expecting anyone else to have to know how to do it. (In CMake, despite using a ne
Review Request: Add missing property alias "animation" in Slider Plasma Component
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104318/ --- Review request for Plasma. Description --- Add missing property alias "animation" in Slider Plasma Component Item now matches it's own documentation. Diffs - plasma/declarativeimports/plasmacomponents/qml/Slider.qml 447dbb1 Diff: http://git.reviewboard.kde.org/r/104318/diff/ Testing --- Tested in Component Gallery (which didn't work before!) Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix padding in ToolButton and TabButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104319/ --- Review request for Plasma. Description --- Fix padding in ToolButton and TabButton between icon and text. This also brings it in line with the regular button which is done properly. Diffs - plasma/declarativeimports/plasmacomponents/qml/TabButton.qml dc8d34a plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0907a22 Diff: http://git.reviewboard.kde.org/r/104319/diff/ Testing --- Opened in Gallery. Screenshots --- Tab Before http://git.reviewboard.kde.org/r/104319/s/473/ Tab After http://git.reviewboard.kde.org/r/104319/s/474/ ToolButton Before http://git.reviewboard.kde.org/r/104319/s/475/ ToolButton After http://git.reviewboard.kde.org/r/104319/s/477/ Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix padding in ToolButton and TabButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104319/#review11509 --- Ship it! Ship It! - Marco Martin On March 17, 2012, 7:44 p.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104319/ > --- > > (Updated March 17, 2012, 7:44 p.m.) > > > Review request for Plasma. > > > Description > --- > > Fix padding in ToolButton and TabButton between icon and text. > > This also brings it in line with the regular button which is done properly. > > > Diffs > - > > plasma/declarativeimports/plasmacomponents/qml/TabButton.qml dc8d34a > plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0907a22 > > Diff: http://git.reviewboard.kde.org/r/104319/diff/ > > > Testing > --- > > Opened in Gallery. > > > Screenshots > --- > > Tab Before > http://git.reviewboard.kde.org/r/104319/s/473/ > Tab After > http://git.reviewboard.kde.org/r/104319/s/474/ > ToolButton Before > http://git.reviewboard.kde.org/r/104319/s/475/ > ToolButton After > http://git.reviewboard.kde.org/r/104319/s/477/ > > > Thanks, > > David Edmundson > > ___ 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
Pedantic Nitpicking Issues in KRunner
Below is a list of really minor "issues" with the default setup of KRunner. Some possibly aren't in KRunner code. I'm just trying to be "taking care of the details", and spend a bit of time trying to find any of the inconsistencies that take a great application away from being absolutely perfect. I'm doing it in the form of an email rather than 12 different bug reports, as if someone else agrees I can just fix them, or open the bugs as needed. Also I quite like the idea of bringing back "reports", I think the KDE Usability team used to do them years ago, though I'm putting an emphasis on "fixing the tiny parts" not "massive rewrites". Anyway, list below: (also available as a pdf: http://static.davidedmundson.co.uk/krunner.pdf) * "Available Features" is a pointless heading 1) "Features" is a new term not used elsewhere in KRunner so it means nothing. The tab heading is "plugins", and the search text says "Search Plugins", so the title if anything should be "Available Plugins". 2) AFAIK we don't list any other type of plugins, so it's a completely useless header anyway. * Inconsistent case in descriptions The majority of descriptions are in sentence case ie. "List and switch between desktop activities". There are three exceptions to this "Open Devices and Folder Bookmarks", "Basic Power Management Operations". and the 'web' in "Allow user to use Konqueror's Web shortcuts". Needless to say they should all be the same, sentence case is the most used currently so should be the standard IMHO. *There is no need to mention KRunner in the title/description of the runner. "Control Amarok with KRunner" should be simply "Control Amarok", and "Nepomuk Desktop Search Runner" should be just "Nepomuk Desktop Search". It's clear from the context (it being a list of krunners) that it is a krunner. Also KRunner is almost a technical term that the user shouldn't need to know. * Typo in Amarok runner Controll Amarok with KRunner -> Control Related, is the help text for Amarok says "Let's Amarok do ", which in English means "let is amaork do " which makes no sense. Also has a fullstop at the end of the description which is inconsistent with all the other plugins. *A lot of descriptions are truncated... Using purely the default runners, with the default krunner, when I click on the spanner/wrench and look through the list of available plugins 8 of the 18 decsriptions are truncated. Obviously with font options and translations this can never be truly solved so that it never happens, but it's wrong for the default setup to be "broken" so much. This is a problem with no single correct solution. Possible options are: 1) Make the default krunner wider 2) Make those descriptions shorter 3) Make the delegate taller and word wrap. * The tab bar does not show which tab you currently have open without mouseover. In a tab bar it is important to show which tab is currently selected without any interaction. * The help view is scrollable, but there is no indication of this. On the desktop, it's not natural to try to scroll on areas without scrollbars. All scroll areas should have scrollbars. *Activities plugin has no icon Suggest the normal activities icon * Recent Documents has no description This makes it stand out as it is the only one. Though I can't think of anything better than "Documents which have been recently opened" which is useless. So I'm not sure. * Inconsistent padding height above and below line edit. Makes the whole thing look not particularly aligned. True as a floating window (10px above, 11px under). (and yes, 1 pixel differences are hugely important!) Looking at the code there's actually a line of code that says "topMargin -= 2" because it was too spacious before. By my calculations it was, but this fix goes slightly too far. When it's sent to "at the top of the screen IMHO the padding is too small too. (in code it's margin/2). (Tbh, this also sounds like working round a bug in the default theme, but I don't want to stray into technical things.) I'd like to stress that I don't want to argue with any conscious decision, only try and spot things where decisions maybe haven't been thought about. * List of available plugins cannot be navigated with arrow keys. * If you have the options "dialog" open, and click on the "?" it closes the options being shown, but doesn't show the help. David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a link to the current desktop folder instead of an icon applet if the desktop is set to folderview on the "Add to Desktop" Kickoff action
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103830/ --- (Updated March 18, 2012, 6:38 a.m.) Review request for Plasma and Aaron J. Seigo. Changes --- use QMetaObject::indexOfSlot to check for addUrl in the target containment This is useful when e.g. the target containmnet is a FolderView, and we need to add a link instead of an Icon applet on triggering the "Add to Desktop" action. Description --- Currently, right-clicking a Kickoff/Classical application launcher entry and selectiong "Add to Desktop" puts an icon applet on the desktop. However, if the desktop is set to Folderview, it is more consistent to add a link to the currently displayed folder. This patch cheks if the "folderview" plugin is used in the desktop containment and performs a KIO::link() if that's the case. Diffs (updated) - plasma/desktop/applets/kickoff/ui/contextmenufactory.cpp 8db9655 Diff: http://git.reviewboard.kde.org/r/103830/diff/ Testing --- Tested, works. Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: add public slot FolderView::addUrl(KUrl)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104328/ --- Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Description --- add public slot FolderView::addUrl(KUrl) This slot can be used e.g. by Kickoff for the "Add to Desktop" action to add a real link instead of an Icon applet. Diffs - plasma/applets/folderview/folderview.h 4e441eb plasma/applets/folderview/folderview.cpp 121d1e7 Diff: http://git.reviewboard.kde.org/r/104328/diff/ Testing --- Tested, works. Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
