I don't see why, it was proposed after mine and it is already merged... Does not seem to need a review.
Thanks for answering though.

Probably the consequence of not reviewing changes? This one can probably be abandoned.

Ping.

Ping.

Sorry but someone will have to also commit for me, I don't have commit access.
Thanks!

Ping.

Updated according to requests.

In D22774#519403, @davidedmundson wrote:

Could you update the title and summary so they reflect what's in the patch now?

This isn't done (or at least phabricator is being unhelpful and not showing it if you have)

Ping.

Anyone?

Ping.

I updated the TextArea element to QtQuickControls 2 (this may not be necessary) and I added a menu with a look more consistent with the rest of Plasma. The menu includes the same actions we had before: undo, redo, copy, cut, paste, delete, clear and select all. In addition, I added a new paste action (now the default paste action), which pastes without formatting. Also, I set the shortcut to remove formatting before pasting.

Hello, I'm not a Plasma expert, but I tried to investigate the situation a bit in Qt and plasma-framework. My understanding is that the notes applet is using TextArea from QtQuick.Controls 1. TextArea 1 creates an edit menu inside Qt, probably the one defined in EditMenu_base.qml. I see it is probably possible to replace this. Not sure if this can be modified, it is not public.

Also notice that the current aspect doesn't look good nor consistent with the rest of Plasma.
In my researches I found this: https://git.reviewboard.kde.org/r/121698/diff/1/#, which is a bit what I'm doing. I'll stop with this until an agreement is found.

I started to reimplement the menu. This is how it looked for me:

I had a look at the code. It is my understanding the menu is provided by Qt and it is probably styled somewhere. Is this correct? I can't find a way to modify it, so I guess I'll have to create an entirely new menu. Before I go on, can someone maybe confirm if I'm on the right track? Thanks!

I'll try to implement that behavior then.

Yes, I couldn't find a better icon so I temporarily used this.

I do not have commit access, can someone do it for me? Thank you guys for your help!

Updated to respect code conventions.

Removed volatile modifier, not probably useful in that context.

This is another implementation that follows the same principle of the previous ones, but moves the responsibility of maintaining the state to the dragHelper object. This requires to postpone the reset of the state after the onRelease event.

Hello! Thank you for your help! I can see the logs now.
Unfortunately I cannot update my patch according to your notes. According to the logs I added, I do not see values that I wouldn't expect. Can you describe somehow how to reproduce the behavior you reported?
Thanks.

Unfortunately I'm not able to get logs from plasma-desktop. Can someone explain how (assuming this is possible) to write logs in this portion of code and read? Or can you point me to docs? I tried to add console.log calls and read using journalctl but I don't see the logs. Can someone help so I can check the values of those variables? Thanks.

Not sure if you already did, but I guess someone will also have to push this to git, sorry.

Yes, all three seem correct. I tested with a couple of resolutions. Server for the test was installed on a Raspberry Pi. It would be interesting to test also with other servers.

Should I add someone else as reviewer (sorry, I'm not an experience KDE dev)?

Thank you: "Luca Carlon <carlon.luca@gmail.com>".

Should I do something else or will someone else take care of committing?

Hello. No, sorry, I don't think I have it.

I added the explicit charset to all scss files.

Happened on KDE Neon in docker.

When QT_NO_OPENSSL is defined, I see that X509 was declared as a class, so I used the same instruction.
In ksslconfig.h I have #define KSSL_HAVE_SSL 0. I don't know if I can recovery much more output, the build succeeded days ago.
Unfortunately I'm not an expert of this section, but I see that libssl-dev is not installed. Maybe that made find() fail?
In any case, if that dep is optional, I guess the build is not supposed to fail, is it?

Unfortunately it would take some time to determine what changed that made this mandatory for me. Maybe some header changed in the hierarchy and the declaration is no more included anymore? Anyway, I cannot build it without declaring it. I'm building in docker using kdeneon/plasma:dev-unstable.