Fix comment

Dan, do you want to review the updated version? The phabricator status is incorrect, this version hasn't been reviewed.

PAINT_SCREEN_TRANSFORMED

QLineEdit has Qt::StrongFocus policy and it is the focus proxy of KPasswordLineEdit. My impression was that KPasswordLineEdit then automatically also had Qt::StrongFocus.

• Add unit tests.

• Require KTextEditor 5.57 and adapt to KTextEditor interface changes

Bloop

A proper margin for [3] can be added at somewhere in the structure of AppletItem and its children for containmnet and TaskItem and its children for the plasmoid...

In D19773#433201, @aacid wrote:

In D19773#431909, @ngraham wrote:

In D19773#431826, @aacid wrote:

Has the HIG updated and decided the search label needs to be removed?

Yes.

Can you point me to it? Because that's not what i saw in the HIG document that was linked from somewhere, the only thing i coudl find was "use ..."

Anyone has a pointer as to why anyone would do that when there's no scarcity of horizontal space?

1. This isn't always the case

That's a very bad excuse, because in *ALL* the cases you've been removing t, it is not the problem.

Cantor doesn't have a problem with the horizontal space, this is correct. However, having both - the label with the text "Find:" and the placeholder text "Find..." in the QLineEdit - doesn't look really nice IMHO. To see what I mean we can have a look at the project explorer in LabPlot:

It's committed now:

• quoting is now not supported at all anymore
• expandText() now returns void

• Drop KWordMacroExpander in favor of own simple implementation (50 slocs)

Thank you so much for the detailed answer. I was able to do [1,2,4,5].
Unfortunately, I do not understand how to add margin in elements in [3]. I tried to use anchor-based margin, but I see that in some files anchor is not used at all, and where it is used, the margin won't affect the appareance at all. I'm sorry to disturb you again, but may I ask you what the correct approach would be here?

Sorry to be pedantic, but we are fixing two different bugs, right? Would it be possible to split this patch into two commits?

In D17790#433960, @apol wrote:

Is openssl interface documented as stable somehow? or could it break anytime?

In D19824#433831, @ngraham wrote:

Thanks for the patch, and for adding a test!

Question: how come the return/enter key currently works for this use case in the open dialog without all this extra code?

rebase

"or because"

Is openssl interface documented as stable somehow? or could it break anytime?

fix dumb value

Alright so I'd like to give RoundButton another chance. Its advantage is that the frame is considerably smaller.

Try using RoundButton

Use typical Breeze background colors

In D19812#433916, @ndavis wrote:

Could you use #eff0f1 and #31363b for the light and dark backgrounds since those are the colors we normally use for window backgrounds?

I split the generation from loading, to a separate function and added some error checks if the key can't be loaded, is empty, etc.

I changed this code so rebasing this is not trivial now :/

I couldn't help spending a little time looking more into this arrow stuff :D I have tried to adjust the down arrow so that it is much smaller and put in the lower right corner of the button, also it doesn't change the size of the button. I guess a screenshot says more then a 1000 words:

Could you use #eff0f1 and #31363b for the light and dark backgrounds since those are the colors we normally use for window backgrounds?

avoid using headings, fix spinbox strings

pushed the revert to both master / applications 19.04

In D19812#432424, @ngraham wrote:

Getting closer:

Scanning dependencies of target generate-web
make[2]: generate_web_data.sh: Command not found
CMakeFiles/generate-web.dir/build.make:57: recipe for target 'CMakeFiles/generate-web' failed

Are you able to test this yourself?

Add ${CMAKE_SOURCE_DIR} prefix to script

Thanks!

In D19841#433885, @hannahk wrote:

In D19841#433880, @vkrause wrote:

If you plan to continue to work on this it might be worth getting commit access, so you can push changes yourself.

I should. I ll find out how soon

Starting with a fresh BUILDROOT, sh osxbuild.sh builddeps fails. Here's the CMakeOutput from BUILDROOT/depbuild/CMakeFiles after running the builddeps command.

In D19841#433880, @vkrause wrote:

Builds fine here too, thanks!

If you plan to continue to work on this it might be worth getting commit access, so you can push changes yourself.