- User Since
- May 13 2017, 6:47 AM (82 w, 6 d)
Thu, Dec 13
This is essentially a re-statement of bug 401587
Resolved by D15979
- Re-Re-Rebase onto Master including D16475
- Clean inequalities
Wed, Dec 12
Sorry this took so long
Sorry, this is going to feel like a tease. This is really good, and I'm sorry I'm so picky :)
- Rebase on master (again)
Rebase on master via D16475
Rebase onto master
Mon, Dec 10
Thu, Dec 6
I like the idea! It is very slick
- It works for me
- I think the operation should be cancel-able, maybe with an 'X' button on the InlineMessage banner to the right of "Choose recipient"
- I think it would be better to not auto-send the message, but just populate the text box and leaving the user to push "Send" as a kind of confirmation. I click wrong buttons all the time, I would like a chance to double-check, especially in this case where there is no undo and potentially real-money cost.
It works for me. I like this a lot better than before because I could never remember how to launch the settings panel! If you like, I can test it on my Ubuntu 18.04 Gnome VM before you merge.
Mon, Dec 3
Sun, Dec 2
Unfortunately, this doesn't work for me
Fri, Nov 30
Wed, Nov 28
This looks great! Thanks very much! Just fix the one small issue blocking message sending before merging, please :)
This is good so far. Thank you!
Let us know if you have any trouble with the rebase. If you did your work on the master branch, you should be able to just do git pull --rebase. If you did your work on a different branch, first change to master, then do git pull, then go back to your branch and do git rebase master
Tue, Nov 27
This is looking really good! I noticed that there seems to be a problem with the privacy options not being per-connection. I hid the contents for Gmail on my computer at home, but now Gmail contents are blocked on my work computer as well! Do you have some way to test with two desktop devices? I can look in to this as well, but I will not have time for at least a week, probably longer
Sun, Nov 25
Go ahead and use my version. There are a few small things I noticed which I will point out after uploading (because the other form doesn't accept comments!)
I haven't completely figured out the problem yet, but one thing I have noticed is that the enable/disable checkbox for an app is no longer saved. This suggests to me that something about the way the database is set up is causing it to either not be read-able or not be write-able. You could check the return value from ourDatabase.insert. If it is -1, it means there was an error.
Sat, Nov 24
I'm happy. I'll leave it for Albert to click the final approval :)
Are there strings (like "@string/remote_control") which are no longer in use? If so, those should probably be removed from res/values/strings/strings.xml
Tue, Nov 20
This is good. Thank you!
I have added a few comments for making the English sound a little more natural, as well as some little fixes
Mon, Nov 19
This is great. Thank you very much!
This is good work! Thank you. Were you able to get the app with this patch working for your own phone? If not, could you share the full stack trace (paste.kde.org) so I can have a look?
Don't forget to mark the GCi task as completed so I can approve it once we get this merged.
Fri, Nov 16
Thu, Nov 15
Nov 14 2018
Is there some disadvantage to keeping things the way they are? From my understanding of the situation, having plugins instantiate a QApplication object is the way KIO wants things to be done (even though the particular commit which caused older plugins to break was a mistake that they have fixed). The .protocol file instead of the .json definitely seems to be the new way as well.
Nov 12 2018
- Rename containsPureText to containsTextBody
- Move messy details of handling RequestConversationWorker into constructor
Nov 10 2018
Tested successfully on Manjaro and Neon, so presumably good
Nov 9 2018
Do we need both PlasmaComponents 2 and PlasmaComponents 3? (Does it make a difference?)
This works on my computer. I have attached a screenshot. The borders, etc. look good with one line as well as many lines
I have been running this patch for about a week and it seems to be working safely (zero crashes) but I'm still concerned about the initial reasoning for not deleting the interface!
Nov 8 2018
It looks like this patch has a dependency on another one. In my version of the repository, I don't have runners/CMakeLists.txt so this patch doesn't apply, and there is no reference to add_subdirectory(runners) in the top-level CMakeLists
Nov 7 2018
- Change Kirigami URL
I see now that this was a compile-time deprecation warning. Looks good to me!
There is no reason to do this. If in the future there is some reason, we may come back to this
With some time to think about this, I think I can combine some of Aleix's last comment. Rather than having the worker inherit from QThread, and rather than implicitly expecting the caller to know a QThread is required, the worker could have a QThread which it is in charge of creating, using, and destroying. I think this would make things much nicer.