Arch Linux

Unfortunately if we enable webkit support in Qt, we could no more provide a separate qtwebkit package.

Maybe if we rebuild qt when qtwebkit is installed this will enable WebKit support in Assistant, but this means that we introduce a circular dependence.

Both solutions are a NOGO for me.

I can accept your argument, the only question is in my mind: Why qtwebkt needs to be in a separate package?
It depends on qt but conflicts only with qt < 4.8, so why need to be separated form qt?

Because qtwebkit development is separate from the qt developement.
Latest QtWebKit (stable) sources are merged in the qt tarball when there's a new qt release, but qtwebkit could release a new stable version after the qt release.

Thanks for the info.
It seems there is not much to do about this. The only way for me, to maintain my own version, because the upstream approach not allows us to deal with this. I must also note: the help of Qt is also displayed incorrectly because of this problem.

I don't know that I should keep this task open (maybe acceptable solution will be available in the future), or make a closure request.

Can you post a screenshot? Do you get the same output of this https://bugs.archlinux.org/task/28042?getfile=8101 ?

I suggest you to try to rebuild the qt package with the qtwebkit package installed and see if this works.

This should be reported upstream IMHO.

No, your picture is from another problem, which is not appeared in this version (I guess that bug is fixed correctly).
I attached screenshots that represents my problem. qthelp-without-css.png is made by my collegue with the original arch version of Qt. qthelp-with-css.png is made using a rebuilt version of Qt with modified PKGBUILD (I removed the -no-webkit configure flag).

About assistant css support: Qt help system uses html based collection as help file (technically it's a webpage extended with index and contents informations). In html we often use css (http://en.wikipedia.org/wiki/Cascading_Style_Sheets) to keep the design (look and feel) separated from the content. Assistant normally uses qtwebkit to render and display these contents. If assistant is built without webkit support, it's falling back to a minimalistic html renderer, with can't handle css, and some other advenced html elements. Because of this, the look and feel of the help can be incorrect, or some special cases (mostly with scaled pictures) can be totally wrong.

I have this same problem, and i am too maintaining my own Qt compiled version because this problem.

I wonder if it's possible to provide both qt versions (one with webkit, another without webkit) in the repo at the same time, because recompiling qt again takes more than 10 hours on my laptop and is a real pain.
I don't know many people who will need the separate qtwebkit package but I guess a lot more people use qtcreator and need to refer to its help, where font can be too small and unchangeable with qt compiled without webkit.

Debian and Ubuntu compiles Qt too without webkit support in last versions so they expose this problem too (i have tested assistant in last Ubuntu version), we can contact Qt developers at development@qt-project.org mailing list and explain the problem, maybe they have a better way to do this or they can fix this for new versions of Qt.

How about moving Assistant out of the qt package into a separate package? That way, assistant could depend on the qtwebkit package without causing a circular dependency between qt and qtwebkit. (Also, qt could have an optional dependency on assistant.) Any reason why that wouldn't work?

Split it is a good idea...I'll do some try

Any progress here?

This will be fixed with the new qt5 packages. But I can't say when they will be in the repos.