Re: Review Request 112234: Save krunner dialog size when manually resized
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112234/ --- (Updated Sept. 1, 2013, 8:25 a.m.) Review request for kde-workspace. Changes --- *bump* Description (updated) --- This size was previously only saved on destruction, which not once has worked, whether I shut down the computer or log out normally. Now it will save (after 1 sec) after manually resizing the dialog. Diffs - krunner/interfaces/default/interface.h a0367a55043aa18229200ca191e2fab1ecb4a32f krunner/interfaces/default/interface.cpp 505e0aa6c02233fba0ff7ae9ce1133e8c7542104 Diff: http://git.reviewboard.kde.org/r/112234/diff/ Testing --- Thanks, Harald Hvaal
Re: Review Request 112258: ksysguard process list: better keyboard navigation
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112258/ --- (Updated Sept. 1, 2013, 8:24 a.m.) Review request for kde-workspace. Changes --- *bump* Description (updated) --- ksysguard has good keyboard handling, but it can be better. For example, it has annoyed me that I cannot use the del/shift-del shortcuts or get the context menu unless I explicitly tab my way down to the treeview (even though pressing up/down with the text field focused gives the false impression that the rows have focus). This diff makes this keyboard navigation more efficient. While the comments in the code should describe the behavior well enough, here they are listed: * Search field ** Pressing enter moves to first item in treeview and opens context menu ** Pressing down/pgdown will move actual focus to the treeview ** Focusing the text field clears the treeview selection. This emphasises that only one visual element is focused at a time, as well as that you can not interact with the items in the view until they have been selected. * Treeview ** Pressing up when on the first entry will move focus to the text field ** If you start typing, the focus will immediately be moved to the text field ** When focus is received, select first row in the treeview Diffs - libs/ksysguard/processui/ksysguardprocesslist.cpp ed2c1ff4e93041e4b1911e2643bfda6888d171bd Diff: http://git.reviewboard.kde.org/r/112258/diff/ Testing --- Thanks, Harald Hvaal
Re: Force push to plasma-framework
On Sun, Sep 1, 2013 at 3:38 AM, Ivan Čukić wrote: > On Sunday 01 September 2013 01:03:59 Ben Cooksley wrote: >> Hi everyone, >> >> Due to an unfortunate accident involving git merge, several branches >> of the plasma-framework repository were rendered unusable. >> >> To correct this, two branches have been forcibly rewound. They are: >> - master: now at ea1b637 >> - ivan/shell-switching: now at f8c2ff5. > > Hi, Hi Ivan, > > Is it something I did wrong? (so that I know for the future) Nope, everything you did was fine. The master branch was already damaged when you merged it into your branch, so it was necessary to rewind your branch as well to ensure the damage was fully removed. > > Cheerio, > Ivan Thanks, Ben > > -- > I don't really trust a sane person. > -- Lyle Alzado >
Re: What to do with KScanDialog
Hi, On Saturday 31 August 2013 20:48:46 Gilles Caulier wrote: > I don't know exactly (i don't know KSCanDialog in fact, so i cannot > compare). > > Ask to kare Sars who maintain this code. I can respond better than me... > The KScanDialog plugin interface is now implemented by the ksaneplugin in kdegraphics (using libksane) and also by libkscan (a plugin) in unmaintained. (Note the difference between ksane and kscan :) I do not see the need for a plugin interface as it is not likely to be implemented and maintained in more than one instance at a time anyways. I think kooka-git also might use the ORC part of the interface but that part has not been maintained for many years in the SC. I have not checked kooka-git tho lately. I would vote to move it to kde4support and deprecate it. I can volunteer to port kolourpaint to libksane if needed. Regards, Kåre > Gilles Caulier > > 2013/8/31 Àlex Fiestas : > > On Saturday 31 August 2013 19:42:02 Gilles Caulier wrote: > >> Hi, > >> > >> libksane in kdegraphics/libs is the right alternative, very well > >> maintained > >> > >> > >> https://projects.kde.org/projects/kde/kdegraphics/libs/libksane > >> > >> It work under Linux and OSX using libsane. Under Windows it use Twain > >> interface. > >> > >> Best > > > > Awesome! > > > > Is there anything like KScanDialog on it? If not, do you think it could be > > interesting to add it? > > > > Cheers !
Re: What to do with KScanDialog
I don't know exactly (i don't know KSCanDialog in fact, so i cannot compare). Ask to kare Sars who maintain this code. I can respond better than me... Gilles Caulier 2013/8/31 Àlex Fiestas : > On Saturday 31 August 2013 19:42:02 Gilles Caulier wrote: >> Hi, >> >> libksane in kdegraphics/libs is the right alternative, very well maintained >> : >> >> https://projects.kde.org/projects/kde/kdegraphics/libs/libksane >> >> It work under Linux and OSX using libsane. Under Windows it use Twain >> interface. >> >> Best > Awesome! > > Is there anything like KScanDialog on it? If not, do you think it could be > interesting to add it? > > Cheers !
Re: What to do with KScanDialog
On Saturday 31 August 2013 19:42:02 Gilles Caulier wrote: > Hi, > > libksane in kdegraphics/libs is the right alternative, very well maintained > : > > https://projects.kde.org/projects/kde/kdegraphics/libs/libksane > > It work under Linux and OSX using libsane. Under Windows it use Twain > interface. > > Best Awesome! Is there anything like KScanDialog on it? If not, do you think it could be interesting to add it? Cheers !
Re: What to do with KScanDialog
Hi, libksane in kdegraphics/libs is the right alternative, very well maintained : https://projects.kde.org/projects/kde/kdegraphics/libs/libksane It work under Linux and OSX using libsane. Under Windows it use Twain interface. Best Gilles Caulier 2013/8/31 Àlex Fiestas : > KScanDialog is currently being used by two apps: kolourpaint and kooka-git > according to lxr. > > This makes me wonder if we should move it to a tier (forcing us to maintain > it) or just move it to kde4support and deprecated it. > > In my opinion if none of the users of this class wants to maintain it we > should move ahead and deprecated it. > > What do you think? > > Cheers. >
What to do with KScanDialog
KScanDialog is currently being used by two apps: kolourpaint and kooka-git according to lxr. This makes me wonder if we should move it to a tier (forcing us to maintain it) or just move it to kde4support and deprecated it. In my opinion if none of the users of this class wants to maintain it we should move ahead and deprecated it. What do you think? Cheers.
Re: Force push to plasma-framework
On Sunday 01 September 2013 01:03:59 Ben Cooksley wrote: > Hi everyone, > > Due to an unfortunate accident involving git merge, several branches > of the plasma-framework repository were rendered unusable. > > To correct this, two branches have been forcibly rewound. They are: > - master: now at ea1b637 > - ivan/shell-switching: now at f8c2ff5. Hi, Is it something I did wrong? (so that I know for the future) Cheerio, Ivan -- I don't really trust a sane person. -- Lyle Alzado
Force push to plasma-framework
Hi everyone, Due to an unfortunate accident involving git merge, several branches of the plasma-framework repository were rendered unusable. To correct this, two branches have been forcibly rewound. They are: - master: now at ea1b637 - ivan/shell-switching: now at f8c2ff5. The following commits have also been blacklisted from entering the repository: - 89894b9ce0347204b7835d476a11ae24ff77ed5c - a793df3c7473b25879491163d622acd988c00a5b - fbb2e749aeaeca987e901e2f0b8046c9f12b578b - 1fc1fda8331254b01f752fb04a8575b051543fb5 - f68ee1a764513db268644365c7879d3bc9f942bd If you have any of the above commits in your current checked out branch, you will need to hard reset it to the upstream version of that branch before continuing. Any commits which you have not yet pushed will need to be cherry picked to the reset branches, or reapplied manually. Do not attempt to rebase your local branch to correct this under any circumstances. Regards, Ben Cooksley KDE Sysadmin
Re: Review Request 112236: krunner: Add the full name of completion matches to history
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112236/ --- (Updated Aug. 31, 2013, 11:34 a.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and Plasma. Description --- Previously you would not record the actual item you chose after choosing an auto-completion, so if you typed say "lal" and you chose a completion way down the list, the history item would not reflect that choice, only what you typed to get to the completion list. This commit will fill the history combo box with the actual hit you executed, instead of half-complete strings that don't make sense until you actually select them. Exact matches are added as-is. example: type ass, and you get Qt Assistant. Instead of adding "ass" to the history, "Qt Assistant" will be added. Diffs - krunner/interfaces/default/interface.cpp 505e0aa6c02233fba0ff7ae9ce1133e8c7542104 kwin/clients/aurorae/themes/plastik/package/contents/ui/main.qml 8832d1d03e47a4e6382877d18ee664ecd4d12343 Diff: http://git.reviewboard.kde.org/r/112236/diff/ Testing --- Thanks, Harald Hvaal
