Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rfc: Using litehtml as the html viewer #1595

Open
Waqar144 opened this issue Jan 26, 2024 · 9 comments
Open

rfc: Using litehtml as the html viewer #1595

Waqar144 opened this issue Jan 26, 2024 · 9 comments

Comments

@Waqar144
Copy link

Currently zeal uses Qt WebEngine for showing the documentation. While it is great, it is also a huge dependency and effectively makes the app more or less equivalent to an electron app. I think litehtml is a library that can be used instead of Qt WebEngine, which is a lightweight html renderer.

Advantages:

  • Small dependency
  • Lower memory usage

Disadvatages

  • No javascript and no dynamic content (perhaps its an advantage).
  • haven't benchmarked, but seems a bit slower e.g., it takes 2s to load the documentation for QString on my laptop with AMD4700U/16G while it is plugged in + high perf profile

Switching wont be a huge effort. I have a wip branch that can be used to try it out. I have only tested it with Qt documentation. If there are documentations that need javascript to work correctly then probably the switch can't be made.

@barolo
Copy link

barolo commented Feb 1, 2024

I have problems building your branch, it is still trying to build itself against webengine.
got wrong source, now it compiles but fails at end, during linking qlitehtml, I have checked the submodule out.
ld: cannot find -lqlitehtml: No such file or directory

Now it fails at building qlitehmtl, and I'm stuck, with errors like: 3rdparty/qlitehtml/src/container_qpainter_p.h:61:52: error: ‘tchar_t’ in namespace ‘litehtml’ does not name a type 61 | litehtml::uint_ptr create_font(const litehtml::tchar_t *faceName,

@Waqar144
Copy link
Author

Waqar144 commented Feb 2, 2024

~ Now it fails at building qlitehmtl, and I'm stuck, with errors like: 3rdparty/qlitehtml/src/container_qpainter_p.h:61:52: error: ‘tchar_t’ in namespace ‘litehtml’ does not name a type 61 | litehtml::uint_ptr create_font(const litehtml::tchar_t *faceName,

Its probably conflicting with your system litehtml. You will have to uninstall it / force the litehtml git submodule to be used by editing the CMakeLists.txt in qlitehtml. I haven't fixed this properly yet.

@barolo
Copy link

barolo commented Feb 2, 2024

~ Now it fails at building qlitehmtl, and I'm stuck, with errors like: 3rdparty/qlitehtml/src/container_qpainter_p.h:61:52: error: ‘tchar_t’ in namespace ‘litehtml’ does not name a type 61 | litehtml::uint_ptr create_font(const litehtml::tchar_t *faceName,

Its probably conflicting with your system litehtml. You will have to uninstall it / force the litehtml git submodule to be used by editing the CMakeLists.txt in qlitehtml. I haven't fixed this properly yet.

This seems to be the case, also the system's litehtml is in its latest version [0.9]. Correct me if I'm wrong but qlitehtml seems to be using quite old version of lite [0.6] which too would have to be fixed, as recent releases made some serious strides in css and layouting capabilities.

@Waqar144
Copy link
Author

Waqar144 commented Feb 2, 2024

its blocked on litehtml/litehtml#266 atm.

@barolo
Copy link

barolo commented Feb 2, 2024

its blocked on litehtml/litehtml#266 atm.

Thanks, managed to compile it with patches provided to qt-review. Very snappy and lightweight, love it.
Renders text really nicely too, recently it looked liked shit in webengine for some reason.

image

@Waqar144
Copy link
Author

The patches in Qt have been merged. I have updated the qlitehtml dependency to latest

@barolo
Copy link

barolo commented Feb 13, 2024

Probably the best solution would be to have two packages, lite and full with webengine. The reason being that not all docs render properly.

@trollixx
Copy link
Member

Very cool! This is something I researched a lot in the past. Unfortunately, too many docsets require JavaScript to render (e.g. all MDN docs). So without regenerating those to not require JS, it'd be impossible to ship this. And given all docsets are coming from Dash, it'd be challenging to also invest in own docsets.

@hhartzer
Copy link

hhartzer commented Mar 7, 2024

This is really cool! I'm curious, is there an issue reported at MDN regarding Javascript rendering to see if they may be open to updating their docs to not require Javascript?

Maybe a stop-gap testing measure for this could be adding a preference to disable Javascript in the rendering to see what happens?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants