Re: Review Request 120000: New Thermal and Electrical Units and Unit Convienience Function for KUnitConversion

[Olivier Churlaud]

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



Except the trailing spaces that are here and there, I didn't see anything to 
say against the patch. Yet as I never worked on the project, I cannot give the 
ship it...


src/unit.h (line 182)


You should remove theses trailing spaces.


- Olivier Churlaud


On July 18, 2016, 11:55 p.m., Garret Wassermann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/12/
> ---
> 
> (Updated July 18, 2016, 11:55 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Repository: kunitconversion
> 
> 
> Description
> ---
> 
> New Thermal and Electrical Units and Convienience Function for KUnitConversion
> 
> 
> Diffs
> -
> 
>   README.md fe8cbe8 
>   src/converter.cpp 921897e 
>   src/electrical_current.cpp PRE-CREATION 
>   src/electrical_current_p.h PRE-CREATION 
>   src/electrical_resistance.cpp PRE-CREATION 
>   src/electrical_resistance_p.h PRE-CREATION 
>   src/energy.cpp be12434 
>   src/thermal_conductivity.cpp PRE-CREATION 
>   src/thermal_conductivity_p.h PRE-CREATION 
>   src/thermal_flux.cpp PRE-CREATION 
>   src/thermal_flux_p.h PRE-CREATION 
>   src/thermal_generation.cpp PRE-CREATION 
>   src/thermal_generation_p.h PRE-CREATION 
>   src/unit.h 9e17624 
>   src/value.h c602150 
>   src/value.cpp 6531f00 
>   src/voltage.cpp PRE-CREATION 
>   src/voltage_p.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/12/diff/
> 
> 
> Testing
> ---
> 
> I added some fundamental (base SI) units as well as some common derived units 
> in SI and English/Imperial system, mostly for electrical or thermal units. I 
> also added a simple member function to the Value class, symbolAsString(), to 
> immediately receive the current unit assigned to the Value object as a 
> QString. I was running into issues with my code where doing 
> v.unit()->symbol() wasn't working because I was getting KSharedPointers 
> instead of the object, and the program would just crash. I just wanted the 
> string! So I made a function, which helped with testing of the units.
> 
> The new categories work fine under my test program. I was able to convert 
> thermal units back and forth in my test program, so seems ok. The values also 
> appear correct from my tests (as long as I didn't mess anything up by hand!).
> 
> First time submitting review, so please let me know if there is something 
> else I should do better next time, thank you.
> 
> 
> Thanks,
> 
> Garret Wassermann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 120000: New Thermal and Electrical Units and Unit Convienience Function for KUnitConversion

[Garret Wassermann]

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

(Updated July 18, 2016, 9:55 p.m.)


Review request for KDE Frameworks and John Layt.


Changes
---

Albert: Added kdeframeworks, guys this is almost 2 years old, can someone have 
a look?


Repository: kunitconversion


Description
---

New Thermal and Electrical Units and Convienience Function for KUnitConversion


Diffs
-

  README.md fe8cbe8 
  src/converter.cpp 921897e 
  src/electrical_current.cpp PRE-CREATION 
  src/electrical_current_p.h PRE-CREATION 
  src/electrical_resistance.cpp PRE-CREATION 
  src/electrical_resistance_p.h PRE-CREATION 
  src/energy.cpp be12434 
  src/thermal_conductivity.cpp PRE-CREATION 
  src/thermal_conductivity_p.h PRE-CREATION 
  src/thermal_flux.cpp PRE-CREATION 
  src/thermal_flux_p.h PRE-CREATION 
  src/thermal_generation.cpp PRE-CREATION 
  src/thermal_generation_p.h PRE-CREATION 
  src/unit.h 9e17624 
  src/value.h c602150 
  src/value.cpp 6531f00 
  src/voltage.cpp PRE-CREATION 
  src/voltage_p.h PRE-CREATION 

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


Testing
---

I added some fundamental (base SI) units as well as some common derived units 
in SI and English/Imperial system, mostly for electrical or thermal units. I 
also added a simple member function to the Value class, symbolAsString(), to 
immediately receive the current unit assigned to the Value object as a QString. 
I was running into issues with my code where doing v.unit()->symbol() wasn't 
working because I was getting KSharedPointers instead of the object, and the 
program would just crash. I just wanted the string! So I made a function, which 
helped with testing of the units.

The new categories work fine under my test program. I was able to convert 
thermal units back and forth in my test program, so seems ok. The values also 
appear correct from my tests (as long as I didn't mess anything up by hand!).

First time submitting review, so please let me know if there is something else 
I should do better next time, thank you.


Thanks,

Garret Wassermann

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Ivan Čukić]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128477: Do not delete system relevant files in tests (if we might succeed)

[David Faure]

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


Ship it!




Wow, it never occured to me that someone might run this test as root. I thought 
it was well known that development should not be done as root ;)
But I can see how it might happen when creating packages with unittests enabled 
or something.

The patch looks fine to me, not sure why you say "it probably still needs some 
more work" ?

Unfortunately I see no other way to test files owned by other users. But of 
course as long as this is tested once, the other tests could change permissions 
on a temp file to get into "missing permissions" error cases.

- David Faure


On July 18, 2016, 5:10 p.m., Tobias Berner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128477/
> ---
> 
> (Updated July 18, 2016, 5:10 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Some tests for kio try to move system relevant files with the blind 
> assumption that 
> the permissions to touch these files is not present. 
> The files are 
> - /etc/passwd
> - /etc/cups
> - /etc
> - /boot
> [sic!].
> 
> 
> Check that the process does not actually have the rights to touch system
> relevant files when running the
> - TestTrash::trashDirectoryOwnedByRoot
> - TestTrash::trashFileOwnedByRoot
> - JobTest::moveFileNoPermissions
> - JobTest::moveDirectoryNoPermissions
> tests -- and bail out of them if so.
> 
> 
> This patch probably still needs some more work [maybe I also missed another 
> naughty test?],
> and I welcome every kind of input on it (apart from the straw man *don't run 
> tests as root* ;) ).
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.cpp 579c507 
>   src/ioslaves/trash/tests/testtrash.cpp c71df13 
> 
> Diff: https://git.reviewboard.kde.org/r/128477/diff/
> 
> 
> Testing
> ---
> 
> Without patch:
> - enjoying two hours of restoring a system without /etc & /boot
> 
> With patch:
> - grep 'must not' Testing/Temporary/LastTest.log.tmp
>  SKIP   : TestTrash::trashFileOwnedByRoot() Test must not be run by root.
>  SKIP   : TestTrash::trashDirectoryOwnedByRoot() Test must not be run by 
> root.
>  SKIP   : JobTest::moveFileNoPermissions() Test must not be run by root.
>  SKIP   : JobTest::moveDirectoryNoPermissions() Test must not be run by 
> root.
> 
> 
> Thanks,
> 
> Tobias Berner
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Ivan Čukić]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Elvis Angelaccio]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Jaime Torres Amate]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Ivan Čukić]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Gregor Mi]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Olivier Churlaud]

> On July 18, 2016, 2:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Review Request 128477: Do not delete system relevant files in tests (if we might succeed)

[Tobias Berner]

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

Review request for KDE Frameworks and Gleb Popov.


Repository: kio


Description
---

Some tests for kio try to move system relevant files with the blind 
assumption that 
the permissions to touch these files is not present. 
The files are 
- /etc/passwd
- /etc/cups
- /etc
- /boot
[sic!].


Check that the process does not actually have the rights to touch system
relevant files when running the
- TestTrash::trashDirectoryOwnedByRoot
- TestTrash::trashFileOwnedByRoot
- JobTest::moveFileNoPermissions
- JobTest::moveDirectoryNoPermissions
tests -- and bail out of them if so.


This patch probably still needs some more work [maybe I also missed another 
naughty test?],
and I welcome every kind of input on it (apart from the straw man *don't run 
tests as root* ;) ).


Diffs
-

  autotests/jobtest.cpp 579c507 
  src/ioslaves/trash/tests/testtrash.cpp c71df13 

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


Testing
---

Without patch:
- enjoying two hours of restoring a system without /etc & /boot

With patch:
- grep 'must not' Testing/Temporary/LastTest.log.tmp
 SKIP   : TestTrash::trashFileOwnedByRoot() Test must not be run by root.
 SKIP   : TestTrash::trashDirectoryOwnedByRoot() Test must not be run by 
root.
 SKIP   : JobTest::moveFileNoPermissions() Test must not be run by root.
 SKIP   : JobTest::moveDirectoryNoPermissions() Test must not be run by 
root.


Thanks,

Tobias Berner

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Ivan Čukić]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Ivan Čukić]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Sebastian Kügler]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.
> 
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
> 
> When I saw the UI, it did not even occur to me that it behaves like this 
> comment suggested. I'd say that is a wrong thing to happen with an UI.
> 
> > To me, the most logical would be:
> >
> >Calculate checksums at the top
> >Under 

Review Request 128476: Add scrollbars to kcm started without systemsettings5

[Olivier Churlaud]

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

Review request for KDE Frameworks and Kai Uwe Broulik.


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


Repository: kcmutils


Description
---

This adds scrollbars when needed.

I cannot manage to get the size of the window right: help on this bit would be 
appreciated.


Diffs
-

  src/kcmultidialog.cpp 22592c4 

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


Testing
---

Compiles, behave as expected (expect for the size)


Thanks,

Olivier Churlaud

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kguiaddons master kf5-qt5 » Linux,gcc - Build # 36 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kguiaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/36/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 13:09:58 +
Build duration: 2 hr 0 min

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 75 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/75/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 14:09:55 +
Build duration: 13 min

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 
39 test(s)Failed: TestSuite.globalcleanuptest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 159/267 (60%)CLASSES 159/267 (60%)LINE 21675/42736 
(51%)CONDITIONAL 14661/36439 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11522/11771 
(98%)CONDITIONAL 8483/16824 (50%)
src.kdecore
FILES 74/93 (80%)CLASSES 74/93 (80%)LINE 9199/16821 
(55%)CONDITIONAL 5715/11771 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9815 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 137 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/137/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 14:02:29 +
Build duration: 1 min 15 sec

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Ivan Čukić]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.
> 
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of 
> user this dialog should work for very well. (I need to verify checksums all 
> the time.)
> 
> To be quite honest, from getting it explained, I get the strong 
> impression that you're overthinking it.
> 
> To me, the most logical would be:
> 
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there 
> to have it compared automatically. 
> 
> That's both, the order of the workflow as well as the logical order of 
> operation. 'Calculate' underneath would raise exactly the same question as I 
> put above: "...but but but ... it could not verify it without calculating it, 
> yet I have to hit a button to calculate ... maybe I should try again and 
> maybe I should just use the commandline to be sure". 
> 
> Point in case: for this kind of stuff, simplicity trumps since it makes 
> it easier to TRUST the dialog. I can't trust anything I don't fully 
> understand or have doubts about, and that's what the groupbox design and the 
> share title cause: doubts.

> See that is why the bottom box was originally called "Share".

When I saw the UI, it did not even occur to me that it behaves like this 
comment suggested. I'd say that is a wrong thing to happen with an UI.

> To me, the most logical would be:
>
>Calculate checksums at the top
>Under that, the input field so I can c/p or type my checksum in there to 
> 

Re: Review Request 128466: Rename Checksums tab to Integrity

[Sebastian Kügler]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?
> 
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course 
> the verification part also does calculation, but it does so without you 
> telling it to. You paste in the checksum, and it tells you whether it matches 
> or not.
> The manual calculation at the bottom is for people who share a file with 
> others and want to accompany it with a checksum for _them_ to verify it.
> 
> I think we might get away with "Calculate" anyway because those who don#t 
> know much about checksums don't need to know that the verify part calculates 
> as well, and those who know it should still be able to use the thing 
> correctly.

That 'Share' title completely puzzled me, and I think I'm the kind of user this 
dialog should work for very well. (I need to verify checksums all the time.)

To be quite honest, from getting it explained, I get the strong impression that 
you're overthinking it.

To me, the most logical would be:

* Calculate checksums at the top
* Under that, the input field so I can c/p or type my checksum in there to have 
it compared automatically. 

That's both, the order of the workflow as well as the logical order of 
operation. 'Calculate' underneath would raise exactly the same question as I 
put above: "...but but but ... it could not verify it without calculating it, 
yet I have to hit a button to calculate ... maybe I should try again and maybe 
I should just use the commandline to be sure". 

Point in case: for this kind of stuff, simplicity trumps since it makes it 
easier to TRUST the dialog. I can't trust anything I don't fully understand or 
have doubts about, and that's what the groupbox design and the share title 
cause: doubts.


- Sebastian


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> 

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 74 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/74/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 13:37:15 +
Build duration: 4 min 24 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 
39 test(s)Failed: TestSuite.globalcleanuptest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 159/267 (60%)CLASSES 159/267 (60%)LINE 21675/42736 
(51%)CONDITIONAL 14661/36439 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11522/11771 
(98%)CONDITIONAL 8483/16824 (50%)
src.kdecore
FILES 74/93 (80%)CLASSES 74/93 (80%)LINE 9199/16821 
(55%)CONDITIONAL 5715/11771 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9815 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.
> 
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum 
> without calculating it?

See _that_ is why the bottom box was originally called "Share". Of course the 
verification part also does calculation, but it does so without you telling it 
to. You paste in the checksum, and it tells you whether it matches or not.
The manual calculation at the bottom is for people who share a file with others 
and want to accompany it with a checksum for _them_ to verify it.

I think we might get away with "Calculate" anyway because those who don#t know 
much about checksums don't need to know that the verify part calculates as 
well, and those who know it should still be able to use the thing correctly.


- Thomas


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___

Jenkins-kde-ci: kdesu master stable-kf5-qt5 » Linux,gcc - Build # 51 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdesu%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/51/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 13:37:15 +
Build duration: 38 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages
  ___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdesu master stable-kf5-qt5 » Linux,gcc - Build # 51 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdesu%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/51/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 13:37:15 +
Build duration: 38 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages
  ___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128464: Allow scrolling in config windows for small screens

[Olivier Churlaud]

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

(Updated July 18, 2016, 1:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Eike Hein.


Changes
---

Submitted with commit 574abcd05ece484da77635e2b8f23d3f4c1af5dd by Olivier 
CHURLAUD to branch master.


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


Repository: kconfigwidgets


Description
---

Often I cannot reach the validation buttons of config windows. With this fix I 
can.

The config page has now scroll bars when needed.


Diffs
-

  src/kconfigdialog.cpp 83c96b6 

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


Testing
---

Compile and tested: Good behavior


Thanks,

Olivier Churlaud

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128464: Allow scrolling in config windows for small screens

[Olivier Churlaud]

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

(Updated July 18, 2016, 3:46 p.m.)


Review request for KDE Frameworks and Eike Hein.


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


Repository: kconfigwidgets


Description
---

Often I cannot reach the validation buttons of config windows. With this fix I 
can.

The config page has now scroll bars when needed.


Diffs
-

  src/kconfigdialog.cpp 83c96b6 

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


Testing
---

Compile and tested: Good behavior


Thanks,

Olivier Churlaud

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Sebastian Kügler]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))
> 
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
> 
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The 
> calculate stuff is just distraction and - worse - potential confusion. If we 
> remove any visual distinction between the two, we just make the situation 
> worse for them.
> 
> I agree that calling the tab "Checksums" is still better, though, because 
> "Integrity" is too vague.
> 
> For the "average user" I just re-tested this with, what would actually 
> help her is creating a second box around the verification part, calling the 
> top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd 
> knew she could simply ignore the whole calculation part.
> 
> Overall simplicity should not be the top priority here: The priority 
> should be to make it clear to users who just want to check whether a download 
> went okay which part they should care about and which they can ignore, while 
> still providing the calculation part for advanced users who want to do that.
> 
> Of course another option would be to split it in two tabs, but that might 
> make the tab bar quite long especially in languages like German.

The latter part seems redundant then. How can you verify a checksum without 
calculating it?


- Sebastian


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kiconthemes master kf5-qt5 » Linux,gcc - Build # 71 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kiconthemes%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/71/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 13:20:17 +
Build duration: 1 min 2 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.kiconengine_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 12/15 (80%)CLASSES 12/15 (80%)LINE 1231/2535 
(49%)CONDITIONAL 802/2041 (39%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 448/463 (97%)CONDITIONAL 
250/524 (48%)
src
FILES 6/9 (67%)CLASSES 6/9 (67%)LINE 783/2072 (38%)CONDITIONAL 
552/1517 (36%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kiconthemes master stable-kf5-qt5 » Linux,gcc - Build # 71 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kiconthemes%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/71/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 13:17:41 +
Build duration: 1 min 2 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.kiconengine_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 12/15 (80%)CLASSES 12/15 (80%)LINE 1231/2535 
(49%)CONDITIONAL 802/2041 (39%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 448/463 (97%)CONDITIONAL 
250/524 (48%)
src
FILES 6/9 (67%)CLASSES 6/9 (67%)LINE 783/2072 (38%)CONDITIONAL 
552/1517 (36%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Thomas Pfeiffer]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
> 
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
> 
> (Take that as "sebas withdraws his objection" :))

Clear -1 to removing the group box.

Here is tha rationale:
For most "regular" users, only the lineedit at the top is relevant. The 
calculate stuff is just distraction and - worse - potential confusion. If we 
remove any visual distinction between the two, we just make the situation worse 
for them.

I agree that calling the tab "Checksums" is still better, though, because 
"Integrity" is too vague.

For the "average user" I just re-tested this with, what would actually help her 
is creating a second box around the verification part, calling the top one 
"Verify checksum" and the bottom "Calculate checksums".
That way if she was told e.g. by a website to verify a checksum, she'd knew she 
could simply ignore the whole calculation part.

Overall simplicity should not be the top priority here: The priority should be 
to make it clear to users who just want to check whether a download went okay 
which part they should care about and which they can ignore, while still 
providing the calculation part for advanced users who want to do that.

Of course another option would be to split it in two tabs, but that might make 
the tab bar quite long especially in languages like German.


- Thomas


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128427: Make sure ECMGeneratePriFile.cmake behaves like the rest of ECM

[Aleix Pol Gonzalez]

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

(Updated July 18, 2016, 1:08 p.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules, KDE Frameworks and Antonio Rojas.


Changes
---

Submitted with commit 5bb92992317a6cf878c823cadac6dd0ccff969d6 by Aleix Pol to 
branch master.


Repository: extra-cmake-modules


Description
---

In `KDEInstallDirs` we have some code to make sure that qmake is asked when the 
project shares the prefix with the installed Qt, to make sure that if something 
was changed in the distribution it would reflect on the projects.
Make sure PRI files are installed using the same reasoning.


Diffs
-

  modules/ECMGeneratePriFile.cmake af4b877 

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


Testing
---

The issue was reported by `arojas`, I haven't been able to reproduce myself.


Thanks,

Aleix Pol Gonzalez

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdesu master stable-kf5-qt5 » Linux,gcc - Build # 50 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdesu%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/50/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 10:54:07 +
Build duration: 2 hr 1 min

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kservice master kf5-qt5 » Linux,gcc - Build # 85 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/85/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 12:50:23 +
Build duration: 3 min 55 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5458/7982 
(68%)CONDITIONAL 2944/6138 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1441/1529 
(94%)CONDITIONAL 881/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1761/3042 
(58%)CONDITIONAL 756/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2040/2798 
(73%)CONDITIONAL 1222/2054 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 105 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/105/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 18 Jul 2016 12:48:51 +
Build duration: 6 min 23 sec

CHANGE SET
Revision 301193cb960beb3b58bd126426e7a33295e02698 by Marco Martin: 
(don#039;t assume last is is numScreens()-1)
  change: edit src/plasma/corona.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 
15 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 8/8 (100%)FILES 79/117 (68%)CLASSES 79/117 (68%)LINE 4884/11782 
(41%)CONDITIONAL 2611/8785 (30%)

By packages
  
autotests
FILES 28/28 (100%)CLASSES 28/28 (100%)LINE 966/1024 
(94%)CONDITIONAL 603/1194 (51%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 644/2096 
(31%)CONDITIONAL 292/1292 (23%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1680/3641 
(46%)CONDITIONAL 955/2722 (35%)
src.plasma.private
FILES 16/26 (62%)CLASSES 16/26 (62%)LINE 968/1802 
(54%)CONDITIONAL 440/1080 (41%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 37/181 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 547/1799 
(30%)CONDITIONAL 299/1407 (21%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1126 (1%)CONDITIONAL 
2/962 (0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kservice master kf5-qt5 » Linux,gcc - Build # 85 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/85/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 12:50:23 +
Build duration: 3 min 55 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5458/7982 
(68%)CONDITIONAL 2944/6138 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1441/1529 
(94%)CONDITIONAL 881/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1761/3042 
(58%)CONDITIONAL 756/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2040/2798 
(73%)CONDITIONAL 1222/2054 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 105 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/105/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 18 Jul 2016 12:48:51 +
Build duration: 2 min 38 sec

CHANGE SET
Revision 301193cb960beb3b58bd126426e7a33295e02698 by Marco Martin: 
(don#039;t assume last is is numScreens()-1)
  change: edit src/plasma/corona.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 13 test(s), Skipped: 0 test(s), Total: 
14 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 8/8 (100%)FILES 76/113 (67%)CLASSES 76/113 (67%)LINE 4466/11311 
(39%)CONDITIONAL 2330/8431 (28%)

By packages
  
autotests
FILES 26/26 (100%)CLASSES 26/26 (100%)LINE 920/977 
(94%)CONDITIONAL 586/1162 (50%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 554/1868 
(30%)CONDITIONAL 206/1142 (18%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1678/3641 
(46%)CONDITIONAL 950/2722 (35%)
src.plasma.private
FILES 15/24 (63%)CLASSES 15/24 (63%)LINE 924/1729 
(53%)CONDITIONAL 421/1034 (41%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 37/181 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 311/1676 
(19%)CONDITIONAL 145/1281 (11%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1126 (1%)CONDITIONAL 
2/962 (0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Sebastian Kügler]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.
> 
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab 
> "Checksums" and removing the groupbox altogether, as it's not providing any 
> semantic value.
> 
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF

This looks logical to me, and it's simpler: Very good!

(Take that as "sebas withdraws his objection" :))


- Sebastian


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Elvis Angelaccio]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...
> 
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
> 
> (Not that I understand the "Share" title in the original review, but 
> that's another matter.)
> 
> This needs more work.

> Perhaps the whole thing could be simplified by naming the tab "Checksums" and 
> removing the groupbox altogether, as it's not providing any semantic value.

Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF


- Elvis


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Sebastian Kügler]

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.
> 
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been 
> involved from the beginning...

It has changed in a significant way, though, making it illogical.

(Not that I understand the "Share" title in the original review, but that's 
another matter.)

This needs more work.


- Sebastian


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


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Kai Uwe Broulik]

> On Juli 18, 2016, 12:05 nachm., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> > 
> > 
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, 
> > but then you can input the checksum above, so essentially, the groupbox is 
> > unnecessary and confusing.
> > 
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" 
> > and removing the groupbox altogether, as it's not providing any semantic 
> > value.
> > 
> > A usability reviewer should have a look.

This dialog has been created in Review 128283 and Usability has been involved 
from the beginning...


- Kai Uwe


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


On Juli 16, 2016, 12:35 nachm., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated Juli 16, 2016, 12:35 nachm.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128466: Rename Checksums tab to Integrity

[Sebastian Kügler]

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



Please don't ship it, yet.


I find the UI illogical. There's a groupbox grouping the checksum buttons, but 
then you can input the checksum above, so essentially, the groupbox is 
unnecessary and confusing.

Perhaps the whole thing could be simplified by naming the tab "Checksums" and 
removing the groupbox altogether, as it's not providing any semantic value.

A usability reviewer should have a look.

- Sebastian Kügler


On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> ---
> 
> (Updated July 16, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we 
> can "free" the Checksums string and use it as the title of the groupbox below 
> (in place of the current `Share` string, which can be confusing).
> 
> Preview in the attached screenshot.
> 
> 
> Diffs
> -
> 
>   src/widgets/checksumswidget.ui 03c64db 
>   src/widgets/kpropertiesdialog.cpp 808765c 
> 
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 73 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/73/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 10:54:07 +
Build duration: 4 min 21 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 
39 test(s)Failed: TestSuite.globalcleanuptest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 159/267 (60%)CLASSES 159/267 (60%)LINE 21675/42736 
(51%)CONDITIONAL 14661/36439 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11522/11771 
(98%)CONDITIONAL 8483/16824 (50%)
src.kdecore
FILES 74/93 (80%)CLASSES 74/93 (80%)LINE 9199/16821 
(55%)CONDITIONAL 5715/11771 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9815 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kiconthemes master stable-kf5-qt5 » Linux,gcc - Build # 70 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kiconthemes%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/70/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 10:41:30 +
Build duration: 1 min 20 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.kiconengine_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 12/15 (80%)CLASSES 12/15 (80%)LINE 1231/2535 
(49%)CONDITIONAL 802/2041 (39%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 448/463 (97%)CONDITIONAL 
250/524 (48%)
src
FILES 6/9 (67%)CLASSES 6/9 (67%)LINE 783/2072 (38%)CONDITIONAL 
552/1517 (36%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kiconthemes master kf5-qt5 » Linux,gcc - Build # 70 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kiconthemes%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/70/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 10:32:39 +
Build duration: 1 min 2 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.kiconengine_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 12/15 (80%)CLASSES 12/15 (80%)LINE 1231/2535 
(49%)CONDITIONAL 802/2041 (39%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 448/463 (97%)CONDITIONAL 
250/524 (48%)
src
FILES 6/9 (67%)CLASSES 6/9 (67%)LINE 783/2072 (38%)CONDITIONAL 
552/1517 (36%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128174: Update AppStream data location

[Jonathan Riddell]

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

(Updated July 18, 2016, 10:23 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Matthias Klumpp.


Changes
---

Submitted with commit 5d10e167854af172b785b5d1f6b50baa09ddb87b by Jonathan 
Riddell to branch master.


Repository: extra-cmake-modules


Description
---

Appstream data changed its preferred location


Diffs
-

  kde-modules/KDEInstallDirs.cmake d9c3b78 

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


Testing
---

nada


Thanks,

Jonathan Riddell

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master kf5-qt5 » Linux,gcc - Build # 74 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/74/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 09:52:00 +
Build duration: 13 min

CHANGE SET
Revision bdf8f3296ce863745894619e90988fab78fe61b0 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/kdecore/all_languages.desktop


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 39 test(s), Skipped: 0 test(s), Total: 
39 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 160/268 (60%)CLASSES 160/268 (60%)LINE 21688/42749 
(51%)CONDITIONAL 14661/36439 (40%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11534/11783 
(98%)CONDITIONAL 8483/16824 (50%)
src.kdecore
FILES 74/93 (80%)CLASSES 74/93 (80%)LINE 9199/16821 
(55%)CONDITIONAL 5715/11771 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 939/9816 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master kf5-qt5 » Linux,gcc - Build # 74 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/74/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 09:52:00 +
Build duration: 13 min

CHANGE SET
Revision bdf8f3296ce863745894619e90988fab78fe61b0 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/kdecore/all_languages.desktop


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 39 test(s), Skipped: 0 test(s), Total: 
39 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 160/268 (60%)CLASSES 160/268 (60%)LINE 21688/42749 
(51%)CONDITIONAL 14661/36439 (40%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11534/11783 
(98%)CONDITIONAL 8483/16824 (50%)
src.kdecore
FILES 74/93 (80%)CLASSES 74/93 (80%)LINE 9199/16821 
(55%)CONDITIONAL 5715/11771 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 939/9816 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 72 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/72/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 09:52:00 +
Build duration: 3 min 41 sec

CHANGE SET
Revision bdf8f3296ce863745894619e90988fab78fe61b0 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/kdecore/all_languages.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 
39 test(s)Failed: TestSuite.globalcleanuptest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 159/267 (60%)CLASSES 159/267 (60%)LINE 21675/42736 
(51%)CONDITIONAL 14661/36439 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11522/11771 
(98%)CONDITIONAL 8483/16824 (50%)
src.kdecore
FILES 74/93 (80%)CLASSES 74/93 (80%)LINE 9199/16821 
(55%)CONDITIONAL 5715/11771 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9815 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kiconthemes master stable-kf5-qt5 » Linux,gcc - Build # 69 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kiconthemes%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/69/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 07:54:53 +
Build duration: 1 min 43 sec

CHANGE SET
Revision 6d1abc297486725c891d14c7fd3169f4575ec86d by David Faure: (KIconLoader: 
massive speed improvement for loading unavailable icons)
  change: edit src/kiconloader.cpp
  change: edit autotests/kiconengine_unittest.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.kiconengine_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 12/15 (80%)CLASSES 12/15 (80%)LINE 1231/2535 
(49%)CONDITIONAL 802/2041 (39%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 448/463 (97%)CONDITIONAL 
250/524 (48%)
src
FILES 6/9 (67%)CLASSES 6/9 (67%)LINE 783/2072 (38%)CONDITIONAL 
552/1517 (36%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kiconthemes master kf5-qt5 » Linux,gcc - Build # 69 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kiconthemes%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/69/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 18 Jul 2016 07:54:53 +
Build duration: 1 min 0 sec

CHANGE SET
Revision 6d1abc297486725c891d14c7fd3169f4575ec86d by David Faure: (KIconLoader: 
massive speed improvement for loading unavailable icons)
  change: edit autotests/kiconengine_unittest.cpp
  change: edit src/kiconloader.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.kiconengine_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 12/15 (80%)CLASSES 12/15 (80%)LINE 1231/2535 
(49%)CONDITIONAL 802/2041 (39%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 448/463 (97%)CONDITIONAL 
250/524 (48%)
src
FILES 6/9 (67%)CLASSES 6/9 (67%)LINE 783/2072 (38%)CONDITIONAL 
552/1517 (36%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128465: KIconLoader: massive speed improvement for loading unavailable icons

[David Faure]

> On July 17, 2016, 10:04 p.m., Mark Gaiser wrote:
> > src/kiconloader.cpp, lines 1714-1715
> > 
> >
> > .constFind()
> > .constEnd()

Haha yes I wrote non-const find/end on purpose because of the erase(it) that 
you suggested in the previous two-hashes approach. But there's no erase 
anymore, so constFind/constEnd it is ;)

Fixed and pushed, thanks to you both for the reviews.


- David


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


On July 18, 2016, 7:54 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128465/
> ---
> 
> (Updated July 18, 2016, 7:54 a.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Feck, David Rosca, Michael Pyne, 
> and Olivier Goffart.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Summary:
> The code said "unknown icons should be searched for anew each time
> [so that installing new icons works]". However this leads to massive
> performance issues when opening the file dialog in a dir with many
> files for which there is no mimetype icon.
> In my case, 293 callgrind.out.* files in one dir (it's ironic that
> they would create a huge performance issue...).
> 
> To make both sides happy (installing new icons should still work, but
> still unknown icons shouldn't lead to a full disk search every time
> icon.isNull() or icon.pixmap() is called), let's re-resolve unknown
> icons again only after 5 seconds.
> 
> Benchmark results for loading an unavailable icon :
> before: 43 msecs per iteration(1897 disk locations checked)
> after: 0.013 msecs per iteration  (pixmap found in the on-disk cache)
> And the file dialog no longer crawls to a halt in the dir with 293 callgrind 
> files.
> 
> Test Plan:
> 
> Reviewers:
> 
> Subscribers:
> 
> 
> Diffs
> -
> 
>   autotests/kiconengine_unittest.cpp 105e86c1e7bc6170c626aa80d34cdb6422acca9c 
>   src/kiconloader.cpp d885318c166f2a996b038218366317615886a14e 
> 
> Diff: https://git.reviewboard.kde.org/r/128465/diff/
> 
> 
> Testing
> ---
> 
> (described in commit log)
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128465: KIconLoader: massive speed improvement for loading unavailable icons

[David Faure]

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

(Updated July 18, 2016, 7:54 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Christoph Feck, David Rosca, Michael Pyne, 
and Olivier Goffart.


Changes
---

Submitted with commit 6d1abc297486725c891d14c7fd3169f4575ec86d by David Faure 
to branch master.


Repository: kiconthemes


Description
---

Summary:
The code said "unknown icons should be searched for anew each time
[so that installing new icons works]". However this leads to massive
performance issues when opening the file dialog in a dir with many
files for which there is no mimetype icon.
In my case, 293 callgrind.out.* files in one dir (it's ironic that
they would create a huge performance issue...).

To make both sides happy (installing new icons should still work, but
still unknown icons shouldn't lead to a full disk search every time
icon.isNull() or icon.pixmap() is called), let's re-resolve unknown
icons again only after 5 seconds.

Benchmark results for loading an unavailable icon :
before: 43 msecs per iteration(1897 disk locations checked)
after: 0.013 msecs per iteration  (pixmap found in the on-disk cache)
And the file dialog no longer crawls to a halt in the dir with 293 callgrind 
files.

Test Plan:

Reviewers:

Subscribers:


Diffs
-

  autotests/kiconengine_unittest.cpp 105e86c1e7bc6170c626aa80d34cdb6422acca9c 
  src/kiconloader.cpp d885318c166f2a996b038218366317615886a14e 

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


Testing
---

(described in commit log)


Thanks,

David Faure

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel