@ognarb and @svuorela has been doing some work, but some is still left

chm plugin is now disabled and okular is on KF6.

Okular is on KF6 now without KJS.
for pdf, Volker ported it.

A first approximation for a solution is to stop building the chm plugin at the KF6 port. I'm not sure if it will happen for the megarelease or not; there does not seem to be much progress.

I think we should wait a bit with formally deprecating. I like add the new, wait a bit, then deprecate.

I've been looking at it for a while, and after trying to decipher the long lambdas, which might have been better as named functions, I think it is, beside Kossebau's comments, fine.

Though maybe give the maintainer a day or two to react as well.

thanks.

@z3ntu - do you have push access to push this?

These are leftovers from when all constructor was public.

I'm not sure I like the implementation. The current AbstractBarcode can also be implemented, at least theoretically, by software providing other barcodes that forever reason isn't available here. I have at least done that for some PoC ports of other things.

Regarding discount. I think the bettetr path moving forward is to port to newer Qt that has markdown handling stuff in QTextDocument

In D23866#553108, @mlaurent wrote:

Ping ? What is the status ?:)

In D23866#535611, @mlaurent wrote:

So what is the status of this patch ?

In D23866#529334, @ltoscano wrote:

Thanks, you have been fast. Would it be possible to use the QWebEngine-based KPart currently in konqueror.git?

Adding Montel because he has experience with locking QtWE down for e.g. mail usage.

Forgot some removed files

Seems to rely quite a bit on the khtml/kio integration and custom url handlers. Maybe there is a way for QtWe to have custom url handling and content serving.

Is the manslave still usefull without the manpart ?

there is a kchmviewer that uses qtwebengine directly for rendering. I don't know how that fits in the okular way of doing things.

Okular uses KHTML for the chm backend.

According to the RFC, the server should ignore case:

After reading the code a bit, I wonder

• can't some of the parsing code be made testable (and tests added)
  • This likely also requires to get rid of the global static.
• rather than poll /proc/mounts every second, I was wondering if one of the filesystem notification things (QFileSystemWatcher, KDirWatch) could tell when to re-parse it

In D20312#445122, @ahmedbilal wrote:

I think unit tests would be nice. Including unit tests documenting the behavior for multiple users with the same full name.

I'm not sure why it as such is needed, but it isn't wrong.

Coding style: it looks like most places in this file uses {} also around one line ifs.

This is the limit of my perl knowledge.

Who sets BUILD_SHARED_LIBS ? I don't see anything in this cmake stuff doing it.

doesn't add_library default to STATIC if not specified? Else we should add that keyword there rather than install the libs. They are just a convenience bundling of related bits in the source tree, not actual libraries.

Let's try poke @mlaurent and see if he has any comments.

In D17152#366536, @ngraham wrote:

What I'm saying is that I think it makes more sense to communicate your preferred email workflow to KMail rather then to Plasma. I'm open to being convinced out of this point of view, of course. :)

In D17152#366525, @ngraham wrote:

In D17152#366495, @anthonyfieroni wrote:

So i like second one, it can still be fixed to 10K+ because it does not matter above.

I'll try with + for a couple of days.

@ngraham I use kmail ... but I have hundreds of thousands unread emails without counting my spam folders. (commit lists, bug lists, ...)

@ngraham It might be that many notifications != no notifications in some cases, but at least in the case of emails, with many unread emails basically doesn't make a difference.

Very much an improvement. But we need a license file.