> 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 that, the input field so I can c/p or type my checksum in > there to have it compared automatically. > > +1 > > Additionally, whe are there 3 buttons for calculating the check-sums. All > those can be calculated in-parallel without any noticeable performance > impact. All of them (IIRC) read the file in 512-bit chunks and perform some > computations. Computations are insignificant compared to file-reads, > performance-wise. > > Thomas Pfeiffer wrote: > Sebas, Ivan, please read the discussion here: > https://git.reviewboard.kde.org/r/128283/ None of the things you're > commenting on here fell from the sky, there were reasons for them. > > As for what is "logical": Yes, this is the logical progression for _you_, > who know how this whole checksum business works. You, however, can also just > use [whatever]sum from the command line. This dialog was designed with users > in mind who don't know how checksum verification works (the vast majority of > "regular" computer users, I can assure you). They don't and need not know > that a checksum has to be calculated first. > All they should need to know is what they should do, and the instruction > at the very top of the dialog explains exactly that. And if they follow those > instructions, they get a result. > > In the first iteration, the dialog just threw three checksums at you, > which leaves ordinary users utterly puzzled (I tried it with one). Plus, > David Faure advised against calculating them automatically, and since he has > a certain reputation of knowing what he's talking about, we followed his > advice. > Of course we could just use one "Calculate" button. > > Still, I don't see a point in making the vast majority of users who just > want to verify a checksum they found a website calculate the checksum first. > > I'm open for ideas on how to separate the two usecases (verifying the > integrity of a file and getting checksums to do whatever with them) better, > but I strongly oppose bothering users who know nothing about checksums with > any information they don't need (and yes, that includes the calculated > checksum, as that is 100% irrelevant to them). > > Sebastian Kügler wrote: > So you're saying that I'm too advanced a user for this dialog to make > sense? I'm at a loss for words here. Maybe you can view Ivan and me as the > kind of user this dialog should be used by and should work for well, and not > try to conveniently place us outside of the target group by just telling us > that the target user is dumber, but still not dumb enough to not need > checksums. This way a bad design doesn't get fixed. > > As to my actual issue, it's not addressed in the review you link, it > rather leaves me more puzzled: > - the checksum must not be calculated automatically (I completely agree, > I don't want my disk to be thrashed once I open this dialog or tab; it's > unrelated to my comment, however) > - so I paste the checksum in there, and then hit calculate (which button, > btw, how do I tell?) > - When I just need the checksum (for example when handing it out with a > file, or to verify a file with a user), I hit calculate, and I can copy the > resulting string? > > For me, calculating the checksum and showing me is what this dialog > really should do. Comparing it to something typed or copy/pasted is an extra, > which can only happen once the checksum has been calculated. Calculating is > clearly the first, necessary step. Why the paste box is above it ... I simply > don't understand. Why a groupbox for the primary function that distinguishes > it from the copy/paste part (which, without calculating is entirely useless) > -- I don't know. It serves no purpose (and none is given in the link you > post). > > I rest my case, the design of this dialog doesn't make a lot of sense as > it is, it can be done simpler, easier to understand and thus, better. > > Ivan Čukić wrote: > Thomas, I have read the discussion before commenting here, although it is > strange to call a mostly one-way conversation (you as the UI expert advising > on the UI) a discussion :) > > I don't see 'we already had a discussion' as a valid answer for users' > confusion with the UI (not only Sebas and me, which is also mentioned in > Rangar's comment in the review #128283) > > I do agree that the two work-flows are separate. Still, the UI does not > make that obvious to me. The UI does not make it obvious that it *has* two > work-flows. > > So, from my point of view, these are the problems: > > - Even if the group says 'Sharing', it does not have any sharing > mechanisms. It would be similar to having the file metadata under a share tab > because somebody would want to share the song name and the artist with > someone; > - If the group is named 'Checksums', it implies that the thing outside is > not a checksum; > - The 'share' workflow is unfortunately a part of the verification > workflow since it needs to calculate the sums; > > > p.s. sharing a checksum is also for advanced users - users that could do > it from CLI. > > Thomas Pfeiffer wrote: > Do whatever you want, I'm outta here. > > Ivan Čukić wrote: > I'm sorry if you are offended, but you need to be open to discuss > potential problems of your work just like everybody else here. > > Olivier Churlaud wrote: > @sebas: the way I understood it (but maybe I'm wrong) is: > > First user case: Check a file. You paste your checksum, and without > clicking anything it goes red or green (or with a small message) and tells > you if it's the good checksum. This mean that you don't need to hit any > [calculate] button. > > Second user case: Share the checksums. You calculate, and copy/paste the > output. > > IMHO they don't need to be in separate tabs but separated with meaningful > titles in the "checksum" tab. > > Thomas Pfeiffer wrote: > > I'm sorry if you are offended, but you need to be open to discuss > potential problems of your work just like everybody else here. > > I do discuss problems with my designs, all the time. But not the way you > (and especially sebas) barged in here, weeks after the original design was > agreed upon with everyone involved in that review request, and telling me > that because it doesn't conform to your logic, it must be wrong. > > I never said it was perfect, there surely are things that can still be > improved, but this discussion is not worth my time. > > Let Elvis decide what to do with his feature. > > Gregor Mi wrote: > I followed this thread closely. I tried to combine > > - the latest screenshot > (https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF) > - with the approach to have the Calculate buttons on the top (although > the primary use case is to "verify a checksum", for me it also makes more > sense that calculation part comes first, because verifing is the second step > and even optional if some just wants to calculate it without verifying > against another checksum) > - more explanatory text (the intro sentenced comes from Wikipedia) to > inform the user > > This is the result: > > ``` > Checksum > -------- > > A checksum provides a means to detect errors in a file which > may have been introduced during its transmission or storage. > > There are different methods to calculate a checksum: > > MD5: [Calculate] > SHA1: [Calculate] > SHA256: [Calculate] > > > If you downloaded this file from a website, it is common that > a checksum is provided so you can verify that the data you > received is valid. > > Paste the given checksum in the field below: > > [Expected checksum (...)] > ``` > > It is more verbose than the original designs and does not tell the user > in advance that if he pastes a checksum that the correct checksum method will > be used and auto-calculated. I assume that he/she will find out when using it > (or a tooltip could be added). > > Olivier Churlaud wrote: > The problem here is that the user must do > > 1) which type of checksum do I want > 2) explicitely calculate > 3) paste the checksum he has. > > The current design makes this better I think: most of the time you only > want to compare 2 checksums, but doing steps that can be automatized (choose > type + calculate)? This is faster, and easier. Then if the user wants to know > the checksum he has, he could explicitely calculate them, but most of them > won't. > > Olivier Churlaud wrote: > Proposition to make things more obvious: > > Can't you hide the [calculate part] so that there is only the option to > paste a string that will be controled, with a "[] More option" check box that > would show the other options (which are "only calculate the checksum"). With > this it is just simple by design. The complexity is only there if the user > needs it. > > This way, the problem raised by Sebas and Ivan would disappear. > > Ivan Čukić wrote: > @Gregor > > +1 (though, like in my previous comment, I don't think we actually need > three separate 'Calculate' buttons) > > Gregor Mi wrote: > @Oliver: > > > The problem here is that the user must do > > > 1) which type of checksum do I want > > 2) explicitely calculate > > 3) paste the checksum he has. > > My suggestion was not to change the functionality when the user pastes > the checksum (the checksum type is automatically detected). So the user _may > not_ do those three steps (but he might think he has to, yes). > > Olivier Churlaud wrote: > > (but he might think he has to, yes). > > This is a usability problem. > > Gregor Mi wrote: > @Ivan: I understand that technically the parallel computation is possible > but does the API allow for it without reading the file again? (I did not look > into the current code) And is this scalable if more methods are added later? > > Gregor Mi wrote: > ``` > Checksum > -------- > > A checksum provides a means to detect errors in a file which > may have been introduced during its transmission or storage. > > There are different methods to calculate a checksum: > > (+) Show ----------------- > | MD5: [Calculate] | > | SHA1: [Calculate] | > | SHA256: [Calculate] | > -------------------------- > > If you downloaded this file from a website, it is common to > provide a checksum so you can verify that the data you > received is valid. > > Paste the given checksum in the field below to trigger > calculation of the file's checksum and verification against > the expected one: > > [Expected checksum (...)] > ``` > > - The "Show" box is initially collapsed (@Ivan: the three Calculate > buttons could be replace with one, but now that they are hidden, it might > matter less) > - The only prompting widget is the "Expected checksum" text box. So, > maybe the user will see it despite the fact that it is at the bottom of the > dialog? (The first time the user would have to read much text but then he/she > knows how the dialog works) > > Thomas Pfeiffer wrote: > >> (but he might think he has to, yes). > > > This is a usability problem. > > Exactly. Again: Users who know little about checksums should not have to > know that technically, a checksum has to be computed first. That's an > implementation detail which is of no concern to users. They paste the > checksum they have in there (like the text tells them to), they get a > response, done. They never have to touch the "calculate" button. > > Gregor Mi wrote: > ``` > Checksum > -------- > > A checksum provides a means to detect errors in a file which > may have been introduced during its transmission or storage. > > (+) Advanced (initially collapsed) ----------------------- > | | > | There are different algorithms to calculate a checksum: | > | | > | MD5: [Calculate] | > | SHA1: [Calculate] | > | SHA256: [Calculate] | > | | > ---------------------------------------------------------- > > If you downloaded this file from a website, it is common to > provide a checksum so you can verify that the data you > received is valid. > > Paste the provided checksum in the field below: > > [Expected checksum (...)] *) > > > > *) Tooltip: "Advanced information: When the checksum is pasted, > at first the correct checksum algorithm is determined, > then the file's checksum is calculated with this algorithm > (if not already done) which then will be verified against the > pasted checksum and finally the result is displayed to you." > ``` > > Olivier Churlaud wrote: > Collapsable area make more sense being below, don't they? At the end you > provide the exact same design in more verbose (too much I think: once you > have read it twice, it must really being nerving). However it's interesting: > Maybe all your text could be in a "What is it for?" tooltip or link. > > I think that having a collapsed advanced menu would solve the issue. It > would be intersting to hear Ivan and Sebas on this. > > And Thomas, what about the usability side of this tooltip/advanced > options? > > I think Elvis has his word to :P > > Thomas Pfeiffer wrote: > I fully agree with everything Olivier said. > > Gregor Mi wrote: > ``` > Checksum > -------- > > If you downloaded this file e.g. from a website which > also provides the expected checksum, then you can verify > if the data you received is valid. > > [ Paste the expected checksum here ] (?)_1 > > ( the initially hidden verification result ) > > (+) Advanced (initially collapsed) ---------------------------- > | | > | There are different algorithms to calculate a checksum: | > | | > | MD5: [Calculate] | > | SHA1: [Calculate] | > | SHA256: [Calculate] | > | | > ---------------------------------------------------------------- > > (?)_1 (What's this link): > A checksum provides a means to detect errors in a file which > may have been introduced during its transmission or storage. > > When text is pasted here, at first the correct checksum algorithm > is determined (currently MD5, SHA1 and SHA256 are supported), > then the file's checksum is calculated with this algorithm > (if not already done) which then will be verified against the > pasted checksum and finally the result is displayed to you. > ``` > > Jaime Torres Amate wrote: > This is totally offtopic (but related to this tab). > I think the user should be informed about the colision problems of MD5: > https://en.wikipedia.org/wiki/MD5 and SHA1: > https://en.wikipedia.org/wiki/SHA-1. i.e. they do not provide, by themselfs, > proof of non modification from http or ftp sites. It is a little bit better > from an https or sftp site if the site has not been compromised. > > Olivier Churlaud wrote: > I think it's not our role to tell them this. Maybe a line in the tooltip > that say SHA256 is recommanded? But not more: we already have a lot of text > here > > Elvis Angelaccio wrote: > > I think the user should be informed about the colision problems of MD5 > > Please let's keep this thread on topic. By the way, there are no > computationally feasible second preimage attacks against MD5 and SHA1, which > means that both algorithms are still fine for file integrity purposes. > > @all: thanks for the impressive amount of feedback, I'm still trying to > read all the replies :p > > Ivan Čukić wrote: > @Olivier > > > I understand that technically the parallel computation is possible > > but does the API allow for it without reading the file again? > > (I did not look into the current code) And is this scalable if > > more methods are added later? > > I haven't checked the API so I can't comment on that. As for scalability, > hashsums need to work on input/forward-only streams (would be quite > problematic if they required random-access) so I'd say it would be > scalable to have one button. > > @Gregor > > I'm not sold on the collapsing thing to be honest. > > @Olivier > > > Collapsable area make more sense being below > > And this is the reason why I'm not sold (though I do like the collapsed > version better than the original one). The fact that it is more logical for > collapsable part of the UI to go below the normal UI does not necessarily > mean that something should be moved below, but that maybe a collapsing UI is > not the right way to go. > > @Jaime > > These hashsums are not meant to be used as tampering-elimination > verification (even if a lot of people do use them for this) but for transfer > verification. > > --- > > Anyhow, *if* collapsing is the way to go, there is no need for any > buttons at all. Paste the hashsum, and during the file hashsum calculation, > the insides of the collapsed part would be filled and shown when the user > un-collapses. > > Alternatively, if the user uncollapses, then it can automatically start > the calculation of the hashes. It has the required pre-action so that it does > not happen every time somebody opens this tab. > > The reason why I like the collapsed version better than the original > proposal is that it removes the initial confusion of 'what is what' when > someone opens the dialogue. > > As for the verbosity of text, I'm not against it. We can expect that the > users who have no idea about checksums will switch to this tab, and a > paste-textbox is not really all they would need to understand what the hell > it is. > > @Elvis > > Sorry for spamming you this much. :) > > Olivier Churlaud wrote: > I agree 100% with what is below the ruler, and I think it brings much: no > more buttons, everything is smooth. > > However I don't understand what is the problem with the proposed design, > if the user knows what is what. For example, I don't see why I, as a user, > would need to explicitely calculate the hashsums. > > I do not see why you would paste the hash AND show the calculated ones. > If you paste, you just say 'your hash is wrong'. No need to show strings that > are worthless: the user won't be able to use this result, and he doesn't need > to compare the strings, as he would be already told that it does not match. > > Gregor Mi wrote: > Jaime: > > I think the user should be informed about the colision problems of MD5 > > Oliver: > > I think it's not our role to tell them this. Maybe a line in the > tooltip that say SHA256 is recommanded? But not more: we already have a lot > of text here > > Ivan: > > These hashsums are not meant to be used as tampering-elimination > verification (even if a lot of people do use them for this) but for transfer > verification. > > If we put the website download example on the dialog, I think it is > important to at least give a hint that there might be security problems of > all kinds. Something like "Please be aware that the security and > trustworthiness in the Internet is a complex matter. Please inform youself > about potential issues when downloading files from the Internet and that > checksums do not provide data authenticity." > > > Ivan: > > Alternatively, if the user uncollapses, then it can automatically start > the calculation of the hashes. It has the required pre-action so that it does > not happen every time somebody opens this tab. > > Good idea. I still wonder how performance will be affected if all three > checksums are calculated at once on a large file (e.g. a DVD image on old > hardware). But maybe one could add "Stop" buttons to each algorithm (similar > to the folder size calculation in the General tab). > > > Oliver: > > I do not see why you would paste the hash AND show the calculated ones. > If you paste, you just say 'your hash is wrong'. > > +1 > > Ivan Čukić wrote: > > I do not see why you would paste the hash AND show the > > calculated ones. If you paste, you just say 'your hash is wrong'. > > One of the mentioned use-cases is 'sharing the checksum' for which you > need to have it shown. > > > Good idea. I still wonder how performance will be affected if all three > checksum [...] > > If they are done with a single pass (single file read), it should be > almost as fast as calculating one of them. I haven't benchmarked, but basing > this on the fact that hash sums require rather simple calculations. > > > "Please be aware that the security and trustworthiness in the Internet > is > > a complex matter. Please inform youself about potential issues when > downloading > > files from the Internet and that checksums do not provide data > authenticity." > > This might be a good solution. What do others think? > > Thomas Pfeiffer wrote: > > One of the mentioned use-cases is 'sharing the checksum' for which you > need to have it shown. > > Yes, but when you want to share the checksum, you don't want to verify > with it. That's the thing: The verification and the "calculate and show > checksums" feature serve different usecases. Either you already have a > checksum from somewhere anduse that to verify the file, then you only need > the paste box and the line below telling you whether it matches or not. If > you want to share checksums, you can safely ignore the paste box. > > Therefore it's fine if the collapsible area is below the paste box, as > there is no two-step process of first showing the calculated checksum and > then verifying with it. > > >> "Please be aware that the security and trustworthiness in the Internet > is a complex matter. Please inform youself about potential issues when > downloading files from the Internet and that checksums do not provide data > authenticity." > > >This might be a good solution. What do others think? > > Makes sense to me! > > Thomas Pfeiffer wrote: > Oh btw, now that we're discussing the whole UI in this review request, > anyway: Is there any feedback given while the checksum is being calculated > when you paste a checksum intop the field? > It should say "Comparing checksums..." in the line where then the result > is shown, so that the user knows that they triggered a process by pasting the > checksum, in case the calculation takes a while. > > Elvis Angelaccio wrote: > I think that replacing the current groupbox with a collapsiblegroubox > might be the best solution: > > * It keeps separated the two use cases, even more separated than the > current design. This should avoid any possible confusion. > * The verification stays at the top of the dialog, which is good because > verifying is much more common than sharing. > * We could remove the three "Calculate" buttons and start the computation > as soon as the box is expanded (though I'm not 100% sure this can be done > without reading the file three times). > > If there is consensus on this proposal, I'm going to discard this review > and open a new one :) > > Ivan Čukić wrote: > @Elvis > > Seems QCryptographicHash does not have the support for this, so without > reimplementing the hash functions (or stealing the QCH implementation), all > the buttons are needed >:| > > Sebastian Kügler wrote: > So the checksums tab is located in the file properties dialog, which is > primarily an informational display. This dialog also holds the size, which is > costly to compute, just like the checksum. The checksums tab serves two > purposes: verify and display the checksum. > > The verification can either be done manually (I read the checksum over > the phone to the dude who has to work in IT support), or I compare it with a > checksum on some website right after downloading the latest rebecca black OS > iso. > > Logically, having the checksum is a pre-requisite for comparing it, so a > lineedit to paste a checksum which is then compared makes sense, but it's a > helper tool. First and foremost, I trust nothing and nobody and want to > actually see the checksum. (Also, if a checksum is different, it shows in the > first few latters in the vast majority of cases, so a quick verification can > easily done with the naked eye.) For those lazy bastards, who copy the > checksum off the website, the lineedit is a handy tool. > > A problem I see with the three button approach is that it provides little > guidance for the user: Which checksum do I want? I think a combo box to pick > the algorithm with md5 as default (as it's the most widely used) would make > this a bit nicer and easier to use. > > As a result, to me, a logical user interface would offer the following: > > - display of current checksum (possibly a hint that it needs to be > computed first for files larger than N?) > - a chooser (in the current approach, three buttons, I think one button + > a combo would be nicer here, see above) > - a way to make comparing easier (the lineedit seems like a nice idea) > > To me, this UI can be very easy, if done right, it displays, allows to > compute (and pick the algorithm) and allows to compare (in that order). > > I think groupboxes, collapsible widgets and advanced sections make this > much harder than it really needs to be. Simplicity can be achieved quite > easily here, and we should aim for that. > > Olivier Churlaud wrote: > As it was clear both sides had different understanding I spoke with Sebas > and Thomas separately to understand what the issue was. > > So Sebas has another user case: > You can get a hashsum over the phone or on IRC but without copying, you > can just compare yourself (while reading) the X first characters of the hash > with your file. So hidding the 'calculate' part is not a good idea. Also it > means that the shown hash *can* be part of the verification process. > Therefore it makes not so much sense to have grouping boxes. Furthermore, > it's too engineered or visually complex to surround 1 lineedit on the one > side, and 3 buttons on the other side in boxes. > > Finally all that is about verifying the checksum. Either you (compare in > the line edit or visually) or someone else (the previously called "share" > user case). They belong together. > > # New proposition > The proposition I do is the following: > In the tab called "Checksum": > > A line edit (with explaining labels, tooltips, whatever): you paste in it > and it becomes either red or green, with a label explaining what happened in > the same color ("the checksum do not match, your file might be corrupted"/ > "the checksums match, your life is beautiful"). **It should also state the > type of algorithm used (MD5, SHA1,...)!** > > ----------A separation line------------ > > A list with MD5/SHA1/SHA256 (and later others?). 2 options IMO: > - for small **local** files you compute directly and display the hash, > for others go to option 2 > - have the name of the algo, followed by a [calculate] button, when > calculated, the button is hidden and replaced by the hash string > sha1: [Calculate] then sha1: sjdljpfiljezflsjls > > # Why does it work for both types of users > > Someone like me or who does not know anything about hashsums will see on > top a field where to paste the hash. He does it, get a green/red response and > everything can be over here. > > Someone like Sebas, who has no trust in this evil code written by Elvis > (:P) will see what algo is used and be able to compare himself, visually, > with the calculated string below, by clicking on the right [calculate] > button. > > Someone like Sebas or Ivan, who know the technicall part and don't want > to use the text field, will directly click on the [calculate] button they are > interested in and do whatever they want with the outcome (share, compare, ...) > > # Finally > In my personal opinion, all has been said. Several designs were proposed > and discussed. I think it's time for Elvis to have his enlighted choice. If > it's not mine, I will think it's suboptimal, but that is life. If it's the > very first one, Sebas will think it's suboptimal, but that's life. Because > I'm not sure more consensus can be found. > > Ivan Čukić wrote: > You will all hate me. > > One additional idea (since we are abusing this review for a general > discussion) - the dialogue might want to check whether there are $FILE.md5sum > $FILE.sha256sum ... in the same folder and check against the checksums in it > automatically. It is often the case that sums are provided as files, not as > copy-paste text. > > Thomas Pfeiffer wrote: > I won't hate you ;) > This is something I just thought about yesterday. Although I'm not sure > if this tab is the right place for it, because people would first have to > know that they have to right-click the file to be checked and select the > checksums tab. > Instead what would make sense to me is to associate the respective > checksum file extensions with a script/application that does the check. That > way people would simple have to click the checksum file to check it. > I had even written a crude bash script using notify-send for this > purpose. It wasn't pretty, but it did the job.
Please note that Frameworks (5.25) enter the string freeze phase from this Saturday, meaning that every change in user-visible strings should land before then. I have no objections to change the current design, but big changes will probably have to wait for the next 5.26 release. @Sebas > Logically, having the checksum is a pre-requisite for comparing it, so a > lineedit to paste a checksum which is then compared makes sense, but it's a > helper tool. First and foremost, I trust nothing and nobody and want to > actually see the checksum. I'm not sure how the groupbox is preventing you from seeing the checksum. I now understand that your primary use case is retrieving the checksums instead of verifying. So now I do agree that using a collapsible/advanced section would be annoying in your case. But is it a groupbox really such a big deal? What about a separation line like Olivier suggests? - 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
