Feature/qwebengine port by xiaoyifang · Pull Request #1447 · goldendict/goldendict

xiaoyifang · 2022-01-30T14:36:58Z

original #1400 PR ,

Drawbacks of this PR:

the webengine and webkit handle the network requests differently. in webkit all the http and https request will finally reach AllowFrameReply which is not the same as webengine. With webengine ,I have not found a solution to intercepte the builtin http & https requests.
The result is: some online dictionaries which works in official version ,can not work in the webengine version.
I think this can be seperated into another PR to handle when a solution come up.
some fixes have no direct connection with qwebengine ,but interwined so close with qwebengine that they can not be seperated easily.

vedgy · 2022-01-30T15:03:15Z

qtsingleapplication/doc/html/qtsingleapplication-example-loader.html 100644 → 100755
Empty file.

Lot's of useless and unrelated changes like that in this PR. Please review the diff yourself.

xiaoyifang · 2022-01-30T15:06:08Z

qtsingleapplication/doc/html/qtsingleapplication-example-loader.html 100644 → 100755
Empty file.

Lot's of useless and unrelated changes like that in this PR. Please review the diff yourself.

this means the files has unchanged. "empty file" is a github bug.
It did show up because I have mistakely remove them ,and I put them back again.

xiaoyifang · 2022-01-30T15:08:24Z

original file:
https://github.com/goldendict/goldendict/blob/master/qtsingleapplication/doc/html/qtsingleapplication-example-loader.html
my branch file:
https://github.com/xiaoyifang/goldendict/blob/feature/qwebengine-port/qtsingleapplication/doc/html/qtsingleapplication-example-loader.html

vedgy · 2022-01-30T15:35:03Z

this means the files has unchanged. "empty file" is a github bug.

You have changed file permissions from 100644 to 100755 (that is, you have made these files executable). Use git rebase -i and edit out any unrelated changes instead of reverting them in later commits.

xiaoyifang · 2022-01-30T15:57:47Z

this means the files has unchanged. "empty file" is a github bug.

You have changed file permissions from 100644 to 100755 (that is, you have made these files executable). Use git rebase -i and edit out any unrelated changes instead of reverting them in later commits.

handled.

vedgy

winlibs/lib/libzstd.a added - unrelated/unneeded I suppose.

I have briefly looked through the changes. Better than before. Still, reviewing would be much easier if Qt4-support code was removed in a separate pull request.

README.md

sptr.hh

vedgy · 2022-01-30T16:53:03Z

winlibs/lib/libzstd.a added - unrelated/unneeded I suppose.

Now this file shows up as deleted. Must have been modified before. Please get rid of this change completely.

vedgy · 2022-01-31T09:07:37Z

I am personally still daunted by the size of this pull request. In the interest of moving forward, I suggest creating a separate small pull request with your Windows iconv fix. As I understand, that fix is independent from the porting. In the commit message describe the motivating issue, what is changed and why. If that small pull request still isn't reviewed by GoldenDict maintainers, a confirmation that the fix works by another Windows user might help.

A tip: refer to goldendict/goldendict issues as e.g. #1448 rather than https://github.com/goldendict/goldendict/issues/1448. Even better, if the issue is completely fixed, write Fixes #1448. in the commit message. This way the fixed issue will be closed automatically once your commit lands in goldendict master.

iconv.cc

vedgy · 2022-01-31T09:11:52Z

Ideally, you should review your own code and make sure that the proposed changes are all useful and relevant to the pull request - before asking others to review the diff. The thing is, you are in a much better position to judge the purpose of your own code changes. So this would definitely improve the review process.

perfect7gentleman · 2022-01-31T14:15:28Z

Is it possible to add FFMPEG-5.0 support ?

fmpegaudio.cc: In member function ‘bool Ffmpeg::DecoderContext::openCodec(QString&)’:
ffmpegaudio.cc:226:32: error: invalid conversion from ‘const AVCodec*’ to ‘AVCodec*’ [-fpermissive]
  226 |   codec_ = avcodec_find_decoder( audioStream_->codecpar->codec_id );
      |            ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                |
      |                                const AVCodec*
ffmpegaudio.cc: In member function ‘bool Ffmpeg::DecoderContext::play(QString&)’:
ffmpegaudio.cc:412:17: warning: ‘void av_init_packet(AVPacket*)’ is deprecated [-Wdeprecated-declarations]
  412 |   av_init_packet( &packet );
      |   ~~~~~~~~~~~~~~^~~~~~~~~~~
In file included from /usr/include/libavcodec/avcodec.h:45,
                 from ffmpegaudio.cc:19:
/usr/include/libavcodec/packet.h:506:6: note: declared here
  506 | void av_init_packet(AVPacket *pkt);
      |      ^~~~~~~~~~~~~~
ffmpegaudio.cc:472:17: warning: ‘void av_init_packet(AVPacket*)’ is deprecated [-Wdeprecated-declarations]
  472 |   av_init_packet( &packet );
      |   ~~~~~~~~~~~~~~^~~~~~~~~~~
In file included from /usr/include/libavcodec/avcodec.h:45,
                 from ffmpegaudio.cc:19:
/usr/include/libavcodec/packet.h:506:6: note: declared here
  506 | void av_init_packet(AVPacket *pkt);
      |      ^~~~~~~~~~~~~~
make: *** [Makefile:4137: build/ffmpegaudio.o] Error 1
make: *** Waiting for unfinished jobs....

vedgy · 2022-01-31T14:33:11Z

@perfect7gentleman, I suggest creating a new issue. This PR is no place for even more changes.

nonwill · 2022-01-31T15:27:36Z

I am personally still daunted by the size of this pull request.

+100
At least 90% of the changes of this pull are nothing on WebEngine porting. And the remaining 10% are of low quality.

nonwill · 2022-02-02T02:54:03Z

Finally, I would like to emphasize that pulls driven by commercial fraudsters are a shame to this project.
Just keep moving on to show the light and hope of GoldenDict. Go for it!

xiaoyifang · 2022-02-02T10:39:19Z

Finally, I would like to emphasize that pulls driven by commercial fraudsters are a shame to this project. Just keep moving on to show the light and hope of GoldenDict. Go for it!

I did not get your point.

nonwill · 2022-02-02T10:45:49Z

Finally, I would like to emphasize that pulls driven by commercial fraudsters are a shame to this project. Just keep moving on to show the light and hope of GoldenDict. Go for it!

I did not get your point.

👍 You are a light of GoldenDict project. Please keep going on for the hope!

xiaoyifang · 2022-02-02T10:48:37Z

Ideally, you should review your own code and make sure that the proposed changes are all useful and relevant to the pull request - before asking others to review the diff. The thing is, you are in a much better position to judge the purpose of your own code changes. So this would definitely improve the review process.

the great difference between webkit and webengine is that ,webkit use sync javscript while webengine use async.
webkit goldendict use a lot js to communicate between code and html ,
including :

found dicts panel updating ,
play sound
others does not work in webengine including:
inspect element
right context menu
preview print
local url scheme
web channel
etc.
all those means we can not simply change some header files and wish it can work.
I can say more than 80% code changes are webengine related. especially compare to original PR port to qt5.15.2 with qwebenginewidgets #1400 .

I also remove some useless code (which actually not about webengine ) by the way.
webengine built with qt>5 that means all the codes written for QT_VERSION<5 are useless. I think these code account for the remaining 20%.

xiaoyifang · 2022-02-02T10:59:08Z

by the way ,remove msbuild folder account for about 6000 lines removed.
though no webengine related but totally not harmful to the project.

vedgy · 2022-02-02T11:23:53Z

So how about creating a separate small pull request with your Windows iconv fix? I cannot properly review the fix as I don't use Windows. Others could review it properly, and it has a chance to be reviewed and merged much sooner than this huge PR.
by the way ,remove msbuild folder account for about 6000 lines removed.

I have no opinion on the usefulness of this directory but GoldenDict maintainers may prefer to keep it. Would be a pity if this unimportant directory prevented merging this PR. Nothing prevents you from creating a simple pull request that removes it right now.

nonwill · 2022-02-02T11:27:02Z

creating a separate small pull request with your Windows iconv fix?

iconv works well on Windows. Please first make sure where is the issue from?

xiaoyifang · 2022-02-02T11:39:51Z

So how about creating a separate small pull request with your Windows iconv fix?

without iconv changes goldendict can not work with dsl and mdx,though great possibility I have used the mismatched iconv .
I can remove it ,but I can never verify the changes (without it) would be correct.

xiaoyifang · 2022-02-02T11:41:39Z

creating a separate small pull request with your Windows iconv fix?

iconv works well on Windows. Please first make sure where is the issue from?

#1322

xiaoyifang · 2022-02-02T12:10:40Z

great
another reason I want to remove iconv is the lib cause more trouble than benifit .
also qtextstream solution offers no less efficiency but also elegant code with only 1/4 of iconv code.

…og too fix: popup link clicked

xiaoyifang · 2022-05-19T01:41:47Z

But if it leads to better design, fewer workarounds and more correctness, then the extra complexity is probably worth it

QWebEnginePage::acceptNavigationRequest has been implemented in commit,it did offer an elegant way to solve this
xiaoyifang/goldendict-ng@4cf2d06

maybe after more tests, can be merge into this PR.

vedgy · 2022-05-19T12:29:45Z

I have started my own porting to Qt WebEngine. High-level differences compared to this PR are:

Qt WebKit remains an option, because otherwise chances of being merged are slim.
More careful coding and error handling.
(planned) Asynchronous JavaScript calls.
Any related and separable fixes will be in separate commits.

This pull request is very useful as a prototype and a rich source of ideas.

I don't care much about external site support as I don't use any. I would rather not sacrifice security to support external sites. If security sacrifices are to be made for that, they should be optional.

vedgy · 2022-05-24T14:06:06Z

articleview.cc

+      url.clear();
+      url.setFragment(hash);
+      ui.definition->page()->runJavaScript(
+          QString("window.location.hash = \"%1\"").arg(QString::fromUtf8(url.toEncoded())));


I am not using MDict dictionaries myself. So hopefully MDict users can clarify this code and change to me:

Doesn't this simplification break some MDict anchor jumps?

The current code in GoldenDict master looks like a risky workaround that could break non-MDict anchor jumps if they happen to have an underscore at the index 33:

int n = anchor.indexOf( '_' ); if( n == 33 ) // MDict pattern: ("g" + dictionary ID (33 chars total))_(articleID(quint64, hex))_(original anchor) n = anchor.indexOf( '_', n + 1 ); else n = 0;

Any idea how to make this workaround more robust and maybe simplify the code to falicitate clean porting to Qt WebEngine?

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

xiaoyifang · 2022-08-19T12:54:32Z

#1542

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

@xiaoyifang

Remove `#if QT_VERSION >= 0x040600` along the way as GoldenDict does not support Qt versions older than 4.6 for several years now. The Qt WebEngine version requires Qt 5.15.2 or later. Qt 5.15.2 was released almost two years ago and is available in latest versions of most major GNU/Linux distributions. The Qt WebEngine version requires C++14 support from the compiler. This is a rather conservative requirement for the standard version released more than 7 years ago. Major compilers support C++14 for many years now. Note that Qt 5.7 requires C++11 and Qt 6.0 requires C++17. QWebEngineHistoryItem has no equivalent of QWebHistoryItem::userData() API. I have tried to store the current article and the coordinates in a container data member of ArticleView. The container had a designated position and mirrored web history. This implementation was shared with the Qt WebKit version. But it turned out that the mirroring of web history is not an easy task. The stored entries and position quickly got out of sync with QWebEngineHistory when the user requested several translations in quick succession, because not every URL, that started to load and appeared in ArticleView::handleUrlChanged(), ended up in web history. So the JavaScript History API is used in the Qt WebEngine version. Unfortunately this API does not work correctly in the Qt WebKit version, not even in the latest Qt 5.15.5 with KDE patches and QtWebKit 5.212.0 Alpha 4. Thus the two versions use different web history APIs. This commit borrows some ideas from @xiaoyifang's unmerged porting pull request goldendict#1447.

xiaoyifang mentioned this pull request Jan 30, 2022

port to qt5.15.2 with qwebenginewidgets #1400

Closed

xiaoyifang force-pushed the feature/qwebengine-port branch from e60d25f to e94e98a Compare January 30, 2022 15:57

vedgy requested changes Jan 30, 2022

View reviewed changes

README.md Outdated Show resolved Hide resolved

sptr.hh Outdated Show resolved Hide resolved

xiaoyifang force-pushed the feature/qwebengine-port branch from e94e98a to 14fc06c Compare January 30, 2022 16:42

xiaoyifang force-pushed the feature/qwebengine-port branch from 14fc06c to 2c57f70 Compare January 31, 2022 00:15

vedgy reviewed Jan 31, 2022

View reviewed changes

iconv.cc Outdated Show resolved Hide resolved

akontsevich mentioned this pull request Jan 31, 2022

Lingvo translations are truncated #1448

Open

xiaoyifang force-pushed the feature/qwebengine-port branch from 90d1dff to e7aea03 Compare February 1, 2022 03:32

xiaoyifang force-pushed the feature/qwebengine-port branch from e7aea03 to b4d581e Compare February 2, 2022 12:12

xiaoyifang added 4 commits February 20, 2022 19:56

fix: iframe auto height

8639eb3

fix:double click translation ,right context menu invalid

2e80121

fix: link click in popup windows ,translation should be in popup dial…

a4f7578

…og too fix: popup link clicked

fix:ctrl+mousescroll to zoomin zoomout

8e6b582

xiaoyifang force-pushed the feature/qwebengine-port branch from 9d3a9dd to 8e6b582 Compare February 20, 2022 11:56

xiaoyifang added 2 commits February 20, 2022 22:49

style format

a7dace0

fix:double click translation

e47c53f

xiaoyifang mentioned this pull request Mar 14, 2022

Google dictionary (en-en) (Oxford) does not work with golden dict. #1416

Open

xiaoyifang mentioned this pull request Mar 28, 2022

Update .gitmodules xiaoyifang/goldendict-ng#34

Closed

vedgy reviewed May 24, 2022

View reviewed changes

xiaoyifang closed this Aug 19, 2022

nonwill mentioned this pull request Dec 17, 2022

sticky groups per tabs #84

Open

nonwill mentioned this pull request Nov 19, 2023

command line version #37

Open

xiaoyifang deleted the feature/qwebengine-port branch January 22, 2024 08:37

Conversation

xiaoyifang commented Jan 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vedgy commented Jan 30, 2022

Uh oh!

xiaoyifang commented Jan 30, 2022

Uh oh!

xiaoyifang commented Jan 30, 2022

Uh oh!

vedgy commented Jan 30, 2022

Uh oh!

xiaoyifang commented Jan 30, 2022

Uh oh!

vedgy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vedgy commented Jan 30, 2022

Uh oh!

vedgy commented Jan 31, 2022

Uh oh!

Uh oh!

vedgy commented Jan 31, 2022

Uh oh!

perfect7gentleman commented Jan 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vedgy commented Jan 31, 2022

Uh oh!

nonwill commented Jan 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nonwill commented Feb 2, 2022

Uh oh!

xiaoyifang commented Feb 2, 2022

Uh oh!

nonwill commented Feb 2, 2022

Uh oh!

xiaoyifang commented Feb 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xiaoyifang commented Feb 2, 2022

Uh oh!

vedgy commented Feb 2, 2022

Uh oh!

nonwill commented Feb 2, 2022

Uh oh!

xiaoyifang commented Feb 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xiaoyifang commented Feb 2, 2022

Uh oh!

xiaoyifang commented Feb 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xiaoyifang commented May 19, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vedgy commented May 19, 2022

Uh oh!

vedgy May 24, 2022

Choose a reason for hiding this comment

Uh oh!

xiaoyifang commented Aug 19, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

xiaoyifang commented Jan 30, 2022 •

edited

Loading

perfect7gentleman commented Jan 31, 2022 •

edited

Loading

nonwill commented Jan 31, 2022 •

edited

Loading

xiaoyifang commented Feb 2, 2022 •

edited

Loading

xiaoyifang commented Feb 2, 2022 •

edited

Loading

xiaoyifang commented Feb 2, 2022 •

edited

Loading

xiaoyifang commented May 19, 2022 •

edited

Loading