• Revert "searchToolbar: Add placeholder for resultInfo in the ui file"

• searchToolbar: Add placeholder for resultInfo in the ui file
• Fix code style and remove unneeded code as requested

OK

@drosca it's building and working for me,
and I changed the files according to your suggestions

@SGOrava @drosca can you check this please.

@drosca @SGOrava is there anything else I could do.

add translator and change name of function.

@SGOrava done. This is what you suggested right.

show notification only once.

That is what you think from user perspective.
But if there is ever any bug which triggers those functions without a break a 1000 times, users will be mad.

@SGOrava with the changes that I did now, the user gets a notification only when he clicks "remember", "update" etc right. I which case he will get only one notification.

fix space issue.

+ as drisca suggested, it would be great to add some stopper for notifications to show only once.
You may see it as "it will show only when there is a problem", well trust him with this, there will be some users who will be spammed with notifications.
I apologize I did not thought about this.

fix space issue

Can you return original blank lines ?
The spacing between lines is there to make it easier to read.

done @SGOrava , is this fine.

remove QMessagebox and use desktop notifications to show notification

I am not that sure about it, you see I am more of a programmer than a designer,
iirc the messagebox will block Falkon until you press it so it is a bit annoying.
Maybe using falkon notifications sounds better.

I actually didn't know what to use exactly and I thought that by using a message box we can also make the user click the close button in which there is a high probability that he will read. the message.

@alukichev done.

created a function for showing the prompt, the previous one was full of unwanted lines

@alukichev sorry, I know this is a bad mistake, will change asap and not repeat it again.
Thanks :)

In D26932#601142, @puneethchanda wrote:

Sorry for making the previous patch a redundant one, I hope this one fixes the issue when KWallet is disabled,
when KWallet is disabled and password is tried to save falkon prompts the user to enable KWallet.

@SGOrava is this fine.

Sorry for making the previous patch a redundant one, I hope this one fixes the issue when KWallet is disabled,
when KWallet is disabled and password is tried to save falkon prompts the user to enable KWallet.

sorry for this, even I thought the same but since it was discussed that it was better than nothing, I did this, if this is not good I am happy with that too.
can I close this, or do you suggest any changes?

I am against this patch.
In my eyes I expect it to just work and to not bother me.
I would welcome notification when it for some reason failed, because that would have some value for users.

remove unnecessary warning and clear white space issues.

In D26872#599904, @drosca wrote:

That's not true. If initialize fails then it doesn't make any sense to keep using the wallet as it is in "inconsistent" state.

In D26872#599903, @SGOrava wrote:

In such case it should be totally rethought since the false can be triggered also by not having write permissions.

In such case it should be totally rethought since the false can be triggered also by not having write permissions.
So i think we should in such case introduce new internal variable to check if we can write into Falkon folder.
Also at first run, we should probably always return true for migration thing, but need to make sure we are in Falkon folder.

Looks fine to me.

SGOrava, changes are made in all the functions described.

updated the given functions to check for the m_wallet instance.

@drosca Even in destructor ?

This check should be in every place where m_wallet is being used.

To be more precise I think the condition should be in these methids

• addEntry
• updateEntry
• updateLastUsed
• removeEntry
• removeAll

Than you can add the condition into all methods.

@SGOrava can you please review this.

add new line.

updated with the suggested changes.

add return and condition to check m_wallet

In D26753#598297, @SGOrava wrote:

I would need your name and email which I can use to commit it for you.
(I can guess, but I want to be sure)

I would need your name and email which I can use to commit it for you.
(I can guess, but I want to be sure)
Thank you.

SGOrava added a comment. View Revision
Do you have commit / push rights ?

No, I don't.

Do you have commit / push rights ?

Thank you for the fix.
Now it looks and works fine.

In D26753#598264, @SGOrava wrote:

OK, works almost fine, only the checkbox disabled state is not triggered at the first launch of preferences dialog.

Changes v3->v4:

• fixed initializing the new checkbox's enabled state upon Preferences construction.

OK, works almost fine, only the checkbox disabled state is not triggered at the first launch of preferences dialog.

In D26753#598233, @alukichev wrote:

In D26753#598232, @SGOrava wrote:

It can be:

• the direct relationship as I said before, we can also think of renaming the pepper plugins option

I think, "Allow Pepper Plugins" reflects it quite adequately, why the need to rename?

Changes v2->v3 (suggested by Juraj Oravec):

• renamed "Allow Pepper Plugins (Flash plugin)" checkbox to "Enable Pepper plugin API (PPAPI)";
• added "(requires PPAPI)" to the new checkbox's text;
• moved the new checkbox directly under "Pepper plugin API".

In D26753#598233, @alukichev wrote:

How about "(requires Pepper)" in the checkbox caption or a "This requires the option \"Allow Pepper Plugins (Flash)\" to be enabled" tooltip?

In D26753#598232, @SGOrava wrote:

It can be:

• the direct relationship as I said before, we can also think of renaming the pepper plugins option

Relationship is now relected by the new checkbox's "enabled/disabled" state, so - done. I think, "Allow Pepper Plugins" reflects it quite adequately, why the need to rename?

I know that.
I still believe we need to do something to make it more obvious or we would just push this work for later date.

Changes v1->v2:

• made the checkbox's "enabled" property value depend on whether pepper plugins are enabled, because of noticed dependency, as suggested by Juraj Oravec.

In D26753#597754, @SGOrava wrote:

So I tested it and it works as intended.

So I tested it and it works as intended.
What I see as a problem is that this patch does not honour the relationship between PDF viewer and Pepper plugins.
So if you disable pepper plugins PDF viewer would also be gone and users would complain.

If there aren't any objections I will land this patch tonight.
It provides the same basic functionality as QtWebEngine default bubble.

So it is even more complicated with this PDF viewer than I thought.
Thank you for making the option.

In D26753#596709, @SGOrava wrote:

It should be optional, many people would like to have internal PDF viewer.

It should be optional, many people would like to have internal PDF viewer.

In D26753#596575, @SGOrava wrote:

It can be disabled by unchecking simple checkbox at:
(Preferences > Browsing > [ ] Allow Pepper Pluginf (Flash player)).