- User Since
- Jun 5 2015, 8:50 PM (159 w, 2 d)
Ok from my side. Probably Dominik also wants to approve.
First of all, thanks for adding this feature. This was missing a long time :-). I will do some comments in the code.
Wed, May 30
To summarize the current reviewers responses,
I agree with the general UI best practice. But this change is different. As far as I understood the program, there are two modes: "Enter/edit a game" and "Play the game". The "Check" action is currently always grayed out during "Play the game" because it makes no sense there. And the "Hint" action only makes sense when playing the game not when creating one. In either mode, the user gets more confused because a deactivated button indicates that it might come available which is not true (as far as I can see it).
The text should use title case: "Kill a Window"
- use auto, add comment
- Handle colon (:) problem for translating and fix one label bug
- Fix comment
- Clean ui file
- Shortcut handling
- Translate the Distro string
- Rename button to 'Copy to Clipboard' for more clarity; and consistency with other applications
- Use a QList of QPairs to collect labels and then use a loop
May 23 2018
- Enable Hint button again when after solved puzzle Undo was used
@rkflx: Hi Henrik, I resolved all your code remarks. Could you look it over and give a go to have this landed.
- clear history on restart
May 16 2018
- Also remove outdated VERSION file
- Bug 357999: improve "Low Difficulty" warning
May 15 2018
- use tabs in files where mostly tabs instead of spaces are used
- change spaces back to tabs
- ksudokuui.rc: increase version
- use tabs instead of spaces
- fix whitespace and improve if statement
This now ready from my side.
- Use qApp->desktopFileName()
- Revert unrelated changes
- Remove not needed Plasma dependency
- Undo unrelated whitespace change
- Clean code
- Use blank lines instead of blocks
May 14 2018
- Apply comments by reviewers:
- move declaration near to usage
- Reuse label texts
Apr 6 2018
I have a question to that because I encountered this issue years ago when I used Thunderbird with Enigmail. I assume the indexing we are talking about here takes place in the local mail client, not in a web client, right? I wonder why incoming encrypted mails are also stored encrypted? Why not always decrypt those mails permanently? This would prevent losing old mail because of lost private key and there would be no problem with indexing. In this Enigmail bug report (https://sourceforge.net/p/enigmail/bugs/1/) from 2003 this request was made. The main reason for not implementing it is a technical one ("this feature is blocked by necessary Thunderbird changes") not fundamental ones. I thought the goal of end-to-end encryption is protect the data when it is underway and not also on the end-points themselves. Are there any reasons why KDE PIM does not decrypt incoming encrypted mail permanently? (or is there already and option to do that? Then sorry for the fuzz)
Mar 30 2018
The inline preview only gives thumbnails which are not usable when one wants to read text on the image (zoom to 100%). For me, the preview should take place before it is uploaded to the web application because I want to make sure the right thing is uploaded.
Mar 13 2018
Any more thoughts on this patch before it is ready to land?
Mar 7 2018
Feb 24 2018
Feb 15 2018
Screenshot looks great.
I identified some of the lost changes in index.docbook and added a new patch: https://phabricator.kde.org/D10542