Review Request 129257: [KNewStuff] Make it possible to query installed entries

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129257/
---

Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

Much like with updates. It will be useful to be able to query for installed 
packages without having to look them all up.


Diffs
-

  src/core/engine.cpp ab47405 
  src/core/engine_p.h 11571bf 
  src/downloadmanager.h 39769f3 
  src/downloadmanager.cpp 8ce813b 

Diff: https://git.reviewboard.kde.org/r/129257/diff/


Testing
---

Works on my newbackends branch for discover where I refactored the internals to 
be more async, there we can just fetch the installed packages at start without 
having to fetch everything.


Thanks,

Aleix Pol Gonzalez

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Albert Astals Cid]

> On Oct. 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)

My suggestion is:

* Cut is Ctrl+X and Shift+Delete by default
* DeleteFile is Shift+Delete by default

**if** both Cut and DeleteFile are used in the same action collection we 
disable Shift+Delete from Cut (only if it's there by default and it was not the 
user that set it on purpose)

That should be *doable* hopefully.


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/#review100230
---


On Oct. 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Oct. 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: KDE Frameworks & Plasma 5.8 LTS

[Dominik Haumann]

On Sun, Oct 23, 2016 at 2:03 PM, Luca Beltrame  wrote:
> Il giorno Sun, 23 Oct 2016 12:14:51 +0200
> Dominik Haumann  ha scritto:
>
>> Do we have any knowledge on whether distributions that ship Plasma 5.8
>> LTS still provide updates to KDE Frameworks 5.27 etc?
>
> openSUSE Tumbleweed will always have the last version of everything
> (barring issues). openSUSE Leap 42.2 will *not* get any major version
> update, so it will stick with Plasma 5.8 and KF 5.26.

If this decision has been made, this is fine.

Still, do you provide minor patches to KF 5.26?

And if so, where do you maintain these patches? Would it make sense to
share this in a public repo?

Greetings
Dominik

Re: KDE Frameworks & Plasma 5.8 LTS

[Dominik Haumann]

Hi Martin,

On Sun, Oct 23, 2016 at 12:38 PM, Martin Steigerwald
 wrote:
> Hi Dominik.
>
> Am Sonntag, 23. Oktober 2016, 12:14:51 CEST schrieb Dominik Haumann:
>> at the Frameworks BoF, the idea was raised to provide updates for the
>> KDE Frameworks 5.26 release, since this is the one that also is
>> typically shipped with the KDE Plasma 5.8 LTS version (at least, that
>> was the argument).
>>
>> Do we follow up on this?
>
> If you want to gather feedback what current distros use, it may make sense to
> also ask on distributions mailing list. I just found your mail as I monitor
> kde-frameworks-ml to some extent.
>
> If its just internal… and you do not intend to gather feedback from distros…
> please disregard my mail.

Actually it's not internal. In fact, I think we can only have a KF
5.26 if distros actively take over part of the maintainership, since
most developers work and test against newest KF version.

But would be nice to gather some infos here as well.

Greetings
Dominik

Re: KDE Frameworks & Plasma 5.8 LTS

[Dominik Haumann]

On Mon, Oct 24, 2016 at 1:47 PM, Ivan Čukić  wrote:
>> 2. We provide KF 5.26.1
>
> This would mean that we should also provide 5.27.1 (and .2, .3) for the
> distros that use KF 5.27 with the LTS release.

I don't think so: As I understand, the distros using KF 5.27 with
Plasma 5.8 LTS plan to continuously update, which is good. So no need
for additional minor releases.

> I'd love to have distros to **properly update KF** during the 5.8 LTS life,
> but if we can not get them to do so, I agree that we need to find an
> alternative.
> [...]

Let's try to get some facts:
1. we only unit test the latest KF on build.kde.org.
2. we typically develop and test against latest KF, so if we patch KF
5.26, it is likely not well / broadly tested.
3. given limited resources / man-power, maintaining additional KF
releases is not easy
4. With a LTS version we'd communicate our commitment to a
well-maintained KF version.

Given these constraints, having a stable KF 5.26 would mean to only
put critical patches into this branch.

It indeed would be much better to convince the distributions to update
continuously and work with KDE upstream. This seems to be the case for
some distributions, which is nice. However, if distributions decide
(for whatever reason) to go with KF 5.26, then we need to work with
them.

Maybe the most convenient way would be to let the distributions commit
the patches into the KF 5.26 branch, i.e. the distributions take over
part of the maintainership.

Greetings
Dominik

Re: Review Request 129253: Support non integer scale factors in kiconengine

[David Edmundson]

> On Oct. 24, 2016, 4:49 p.m., Jarosław Staniek wrote:
> > > didn't look blurry on mouseover
> > 
> > Did you test particular theme or can we assume lines are sharp regardless 
> > of theme?
> > 
> > (for the record, when I removed 24x24 icons I got blurry icons for default 
> > Windows style on Windows as 24px is a standard for toolbars)
> 
> Christoph Feck wrote:
> Native Windows applications do not scale the icon size if you increase 
> the global scaling in the Control Panel?

We know this fix will always give as sharp or sharper images than it does 
currently, regardless of theme. Your issue is something unrelated.

Qt originally had DPRs being floats everywhere except 
QPaintEngine::devicePixelRatio which was some sort of oversight; but not one 
that mattered because the backends enforced integer scaling anyway. At 5.6 they 
changed that in the backend, but for API reasons had to introduce a new method 
QPaintDevice::devicePixelRatioF.

Without this fix, the client code can end up trying to paint an icon of DPR 2 
into a pixmap of DPR 2.3  and that will involve some an extra scaling operation 
that shouldn't exist.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129253/#review100239
---


On Oct. 24, 2016, 3:06 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129253/
> ---
> 
> (Updated Oct. 24, 2016, 3:06 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Support non integer scale factors in kiconengine
> 
> 
> Diffs
> -
> 
>   src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe 
> 
> Diff: https://git.reviewboard.kde.org/r/129253/diff/
> 
> 
> Testing
> ---
> 
> Ran system settings with QT_SCALE_FACTOR=2.3 
> didn't look blurry on mouseover
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 129253: Support non integer scale factors in kiconengine

[Christoph Feck]

> On Oct. 24, 2016, 6:49 p.m., Jarosław Staniek wrote:
> > > didn't look blurry on mouseover
> > 
> > Did you test particular theme or can we assume lines are sharp regardless 
> > of theme?
> > 
> > (for the record, when I removed 24x24 icons I got blurry icons for default 
> > Windows style on Windows as 24px is a standard for toolbars)

Native Windows applications do not scale the icon size if you increase the 
global scaling in the Control Panel?


- Christoph


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129253/#review100239
---


On Oct. 24, 2016, 5:06 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129253/
> ---
> 
> (Updated Oct. 24, 2016, 5:06 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Support non integer scale factors in kiconengine
> 
> 
> Diffs
> -
> 
>   src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe 
> 
> Diff: https://git.reviewboard.kde.org/r/129253/diff/
> 
> 
> Testing
> ---
> 
> Ran system settings with QT_SCALE_FACTOR=2.3 
> didn't look blurry on mouseover
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 129253: Support non integer scale factors in kiconengine

[Christoph Feck]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129253/#review100240
---


Ship it!




- Christoph Feck


On Oct. 24, 2016, 5:06 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129253/
> ---
> 
> (Updated Oct. 24, 2016, 5:06 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Support non integer scale factors in kiconengine
> 
> 
> Diffs
> -
> 
>   src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe 
> 
> Diff: https://git.reviewboard.kde.org/r/129253/diff/
> 
> 
> Testing
> ---
> 
> Ran system settings with QT_SCALE_FACTOR=2.3 
> didn't look blurry on mouseover
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 129253: Support non integer scale factors in kiconengine

[Jarosław Staniek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129253/#review100239
---



> didn't look blurry on mouseover

Did you test particular theme or can we assume lines are sharp regardless of 
theme?

(for the record, when I removed 24x24 icons I got blurry icons for default 
Windows style on Windows as 24px is a standard for toolbars)

- Jarosław Staniek


On Oct. 24, 2016, 5:06 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129253/
> ---
> 
> (Updated Oct. 24, 2016, 5:06 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Support non integer scale factors in kiconengine
> 
> 
> Diffs
> -
> 
>   src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe 
> 
> Diff: https://git.reviewboard.kde.org/r/129253/diff/
> 
> 
> Testing
> ---
> 
> Ran system settings with QT_SCALE_FACTOR=2.3 
> didn't look blurry on mouseover
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Review Request 129253: Support non integer scale factors in kiconengine

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129253/
---

Review request for KDE Frameworks and Christoph Feck.


Repository: kiconthemes


Description
---

Support non integer scale factors in kiconengine


Diffs
-

  src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe 

Diff: https://git.reviewboard.kde.org/r/129253/diff/


Testing
---

Ran system settings with QT_SCALE_FACTOR=2.3 
didn't look blurry on mouseover


Thanks,

David Edmundson

Review Request 129252: Support non integer scale factors in KFileDelegate

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129252/
---

Review request for KDE Frameworks.


Repository: kio


Description
---

Support non integer scale factors in KFileDelegate


Diffs
-

  src/widgets/kfileitemdelegate.cpp 9a40b7c24d8f91600907bccbf32d70aeb78eaa2e 

Diff: https://git.reviewboard.kde.org/r/129252/diff/


Testing
---

Ran system settings with QT_SCALE_FACTOR=2.3 
didn't look blurry on mouseover


Thanks,

David Edmundson

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Heiko Tietze]

> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?

1. Do we want to retain IBM shortcuts used for decades? Yes, keep shift+del as 
alternative to ctrl+X; No, drop the unknown shortcut.
2a. If 1)=Yes, do we want to have a similar shortcut for permanently delete? 
Yes, meta+del/alt+del... No, use something completely different and app specific
2b. If 1)=No, do we want to have an easy shortcut for destructive functions? 
Yes, use ctrl+del for convenience. No, make it hard to unintentionally run 
destructive functions; rather use shift+alt+del/ctrl+alt+del or the like.

(My take is 2b and No; but it has to work in _every_ KDE app unless the app 
defines its own behavior)


- Heiko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/#review100230
---


On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Okt. 24, 2016, 10:47 vorm.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Elvis Angelaccio]

> On Oct. 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.

Thanks for the link. So if I understand the issue correctly, we should first 
agree upon another primary shortcut for "Force Delete" and replace Shift+Del 
with that, at least in KConfig. What about Meta+Del like Thomas suggested?


- Elvis


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/#review100230
---


On Oct. 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Oct. 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: KDE Frameworks & Plasma 5.8 LTS

[Ivan Čukić]

> 2. We provide KF 5.26.1

This would mean that we should also provide 5.27.1 (and .2, .3) for the
distros that use KF 5.27 with the LTS release.

I'd love to have distros to **properly update KF** during the 5.8 LTS life,
but if we can not get them to do so, I agree that we need to find an
alternative.

Keeping a list of bug-fix patches is one option, but we would need to keep
the list for each future release of KF which might be problematic. But,
if we had a common place to put them, it might be an OK option.

The same would go for the point releases. It would require some additional
work to tag the point releases in Git.

I think the list of patches might be easier to pull off -- we would not
need to provide releases for all frameworks -- just for those that need
to be updated. This way, the distros would know which ones need updating
at all.

Cheers,
Ivan

--

KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Heiko Tietze]

> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?

This question was asked last year on the mailing list 
https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
Shift+Del dates back to the medieval ages but was never reverted and is still 
in our HIG. The discussion didn't end with a solution. And I strongly suggest 
to have a generic solution that works in all programs. Btw, Krusader uses 
Shift+Del for permanently delete files.


- Heiko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/#review100230
---


On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Okt. 24, 2016, 10:47 vorm.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Elvis Angelaccio]

> On Oct. 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"

Ah, sorry I didn't know that. Still, the conflict is caused by kconfig itself 
and it's being worked around by applications. What should we do then?


- Elvis


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/#review100230
---


On Oct. 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Oct. 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/#review100230
---



-1 it's an established shortcut for cut too. even 
https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut the 
selection and store it in the clipboard"

- Albert Astals Cid


On Oct. 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Oct. 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

[Elvis Angelaccio]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129251/
---

Review request for KDE Frameworks, KDE Usability and Matthew Dawson.


Bugs: 357747
https://bugs.kde.org/show_bug.cgi?id=357747


Repository: kconfig


Description
---

This patch removes Shift+Del as secondary shortcut for the Cut action. This 
shortcut was set back in 2001.

Reasons for removing it:

* The expected standard behavior for this shortcut is "Permanently delete"
* For the reason above, it is also set as primary shortcut for the `DeleteFile` 
action. This causes conflicts in applications.
* For the reason above, many applications (e.g. Dolphin or Digikam) already 
resolve this conflict on their own.

Credits to Jan for the investigation: 
https://bugs.kde.org/show_bug.cgi?id=347373#c2


Diffs
-

  src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 

Diff: https://git.reviewboard.kde.org/r/129251/diff/


Testing
---

Using Shift+Del in Gwenview now works as expected.


Thanks,

Elvis Angelaccio

Re: Review Request 129188: Add documentation for the GenerateProperties option

[Elvis Angelaccio]

> On Oct. 16, 2016, 2:38 p.m., Aleix Pol Gonzalez wrote:
> > src/kconfig_compiler/README.dox, line 216
> > 
> >
> > Are you sure this is needed? maybe we could make it so it's not needed? 
> > Looks the kind of thing that will generate crazy errors, hard to figure out.
> 
> Elvis Angelaccio wrote:
> It won't compile without (unless I'm doing something wrong). 
> GenerateProperties adds "include xxx.moc" in the generated xxx.cpp file, but 
> the compiler doesn't find xxx.moc without the GENERATE_MOC option. I don't 
> know exactly how cmake handles the moc, but maybe xxx.{h,cpp} are generated 
> after automoc has already been run?
> 
> Albert Astals Cid wrote:
> @Aleix: Honestly i think you're putting an unreasonable request to Elvis, 
> he's just documenting a missing feature from the docs, and while doing that 
> you're asking him to fix a bug, that while unrelated is in my opinion out of 
> scope for this review request, i think what's fair is
> 
> * Commit this
> * Open a bug about the need of using GENERATE_MOC and see if we can get 
> that fixed.
> 
> What do you think?
> 
> Aleix Pol Gonzalez wrote:
> Yes, I guess you are right, it's out of scope. If you can commit this, 
> it's already a step forward. If you can create a bug and assign it to me, 
> that would be perfect.

There you go :) https://bugs.kde.org/show_bug.cgi?id=371562


- Elvis


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129188/#review100043
---


On Oct. 24, 2016, 9:45 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129188/
> ---
> 
> (Updated Oct. 24, 2016, 9:45 a.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> The `GenerateProperties` option is missing from: 
> https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html
> 
> This patch explains what the option does and how to use it.
> 
> 
> Diffs
> -
> 
>   src/kconfig_compiler/README.dox b9606f1d157229a22afbeaea7d56ee95732762a2 
> 
> Diff: https://git.reviewboard.kde.org/r/129188/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: Review Request 129188: Add documentation for the GenerateProperties option

[Elvis Angelaccio]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129188/
---

(Updated Oct. 24, 2016, 9:45 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Matthew Dawson.


Changes
---

Submitted with commit 3a7b8ae9c9b151c20e7b1f9d7f01aa2013a9b25f by Elvis 
Angelaccio to branch master.


Repository: kconfig


Description
---

The `GenerateProperties` option is missing from: 
https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html

This patch explains what the option does and how to use it.


Diffs
-

  src/kconfig_compiler/README.dox b9606f1d157229a22afbeaea7d56ee95732762a2 

Diff: https://git.reviewboard.kde.org/r/129188/diff/


Testing
---


Thanks,

Elvis Angelaccio

Re: Review Request 129205: [kcoredirlister] Ability to watch files changes

[Anthony Fieroni]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129205/
---

(Updated Oct. 24, 2016, 10:05 a.m.)


Review request for KDE Frameworks and David Faure.


Changes
---

Test case


Repository: kio


Description
---

David, i will discard review if you don't like it, cause watching files changes 
can be *really* expensive. I try to:
1. to not break abi compability
2. to extend filenamesearch with this option
3. to fix https://git.reviewboard.kde.org/r/129141/


Diffs (updated)
-

  src/core/kcoredirlister.h e6ba2ac 
  src/core/kcoredirlister.cpp 508516e 
  src/core/kcoredirlister_p.h 9a3cc7b 
  tests/kdirlistertest_gui.h 8316b20 
  tests/kdirlistertest_gui.cpp 11e89cf 

Diff: https://git.reviewboard.kde.org/r/129205/diff/


Testing
---

For 3. i still can't figure out why in filenamesearch signal for delete item(s) 
is not triggered.
1. Search for file (by name) in dolphin
2. When appear in view delete him
3. Signal ItemsDeleted is not triggered, file stays in the view even if new 
search is performed and reload is needed. The cache look good, tests pass, 
works but in filenamesearch.


Thanks,

Anthony Fieroni