OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Internet => Topic started by: Dave Yeo on August 22, 2024, 07:43:14 am
-
Here's a quick build of the latest Dooble release, Qt6 version. Needs Paul's Qt6 environment.
I'll package it better later as well as build a Qt5 RPM.
See the release notes under help.
Curious if people want any translations included in the package, or perhaps a separate package of translations. There's 24 MB's of translations so best to not include all of them. Not totally sure how they work either. Hopefully simply by locale.
-
Hi Dave,
Thanks again for your nice work. I my case I would like to have the German language available.
Greetings, Mike
-
Hi Dave,
thanks for keeping dooble uptodate.
The new version works very well, but it generates a "dooble_settings.db" in the root directory.
best regards
Bernhard
-
Seems to run nicely, just testet very little with few sites.
Best regards
Rene
-
Hi Dave,
thanks for keeping dooble uptodate.
The new version works very well, but it generates a "dooble_settings.db" in the root directory.
best regards
Bernhard
Sorry about that, it is a weird bug only on OS/2 dependent on how things are initialized at the start of the program. The merge removed one line.
This binary should fix it. I removed the binary from the first post.
-
Thanks Dave - it's working well here!
There is a long standing bug in Dooble on OS/2 where if you try to open an HTML file, it always says 'Your file couldn't be accessed' even though you just clicked on it. However, if that file is on your %UNIXROOT% drive (say C:), and you remove 'C:' from the address bar with that file name on it, the file is displayed. If it is not on the %UNIXROOT% drive, removing, say 'D:' does not help and can not be displayed.
The implication is the code is using a Linux standard to find the file (no drive letters) so it works this way only on the %UNIXROOT% drive. But the Windows version of Dooble does use drive letters and it does work, so it seems there must be a code path available to use drive letters when displaying files if needed.
Are you familiar with this? Has it been looked at in the past? The reason it is important to me is I would like to use Dooble to display e-mail messages from PMMail, but it doesn't work because PMMail is not on %UNIXROOT% so even removing the drive letter doesn't help in that case. Seems like there should be a straight forward solution to this, if the proper code was identified...
Regards,
-
I searched the dooble code for Q_OS_WINDOWS and I don't see anything obvious. I suspect it may be using a Qt API that is using the unix code path not a windows path on OS/2.
-
Hi Dave,
Thanks again for your nice work. I my case I would like to have the German language available.
Greetings, Mike
Here you go for testing purposes. Let us know if you can get them to work. Alex says that the %LANG% variable is the usual way for Qt apps to find their locale. See the included readme from upstream. Not sure if drive letters will work or which path separator to use in DOOBLE_TRANSLATIONS_PATH
-
Hi David, as Paul says, the file stuff seems to come from the Web engine or simply Qt.
Playing around a bit, there seems to be some weird rules at play. As you say, drive letters aren't recognized, some variables are.
Using a small html file I had laying around, Node.html and copying to various places, I found these work.
file:///@unixroot//Node.html and file:///@tmpdir//Node.html using %UNIXROOT% and %TMPDIR%
file:///etc/Node.html opens the Node.html in \mptn\etc
file:///tmp/Node.html opens the Node.html in %TMP%, same as %TMPDIR%
Meanwhile things like file:///home/Node.html does not work.
Not sure what the rules are here but it may be possible to have an environmental variable pointing to your PMMail location or perhaps a symlink in @unixroot pointing at your PMMail directory
-
I'll have a poke around the chromium/qtwebengine code...
I reckon this might be it: https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/url/url_canon_unittest.cc#L2091
Oops that's the unittest - but I reckon the solution is in the source folder....
-
<sigh> build stops regenerating .gn files and trying to work out what's going on, git diff is giving a SIGSEGV. Why is everything so hard?
-
<sigh> [listing of woes] Why is everything so hard?
In Ancient Times folk would have said something like, "God is testing you for a Great Task, so go with it." These days, dunno. Maybe you're due to have one of those life-rebooting Road To Damascus Warpstock experiences in due course.
-
Thanks Dave - it's working well here!
There is a long standing bug in Dooble on OS/2 where if you try to open an HTML file, it always says 'Your file couldn't be accessed' even though you just clicked on it. However, if that file is on your %UNIXROOT% drive (say C:), and you remove 'C:' from the address bar with that file name on it, the file is displayed. If it is not on the %UNIXROOT% drive, removing, say 'D:' does not help and can not be displayed.
The implication is the code is using a Linux standard to find the file (no drive letters) so it works this way only on the %UNIXROOT% drive. But the Windows version of Dooble does use drive letters and it does work, so it seems there must be a code path available to use drive letters when displaying files if needed.
Are you familiar with this? Has it been looked at in the past? The reason it is important to me is I would like to use Dooble to display e-mail messages from PMMail, but it doesn't work because PMMail is not on %UNIXROOT% so even removing the drive letter doesn't help in that case. Seems like there should be a straight forward solution to this, if the proper code was identified...
Regards,
I vaguely remember that Dmitry already had a fix in place that went into a test version of one of the Qt5 DLLs. I just cannot remember which one that was ...
-
Hey, thanks everyone for looking into this bug. Too bad it isn't as straight forward as I hoped. I have other QT apps (like Scribus) that handle drive letters just fine, but I guess the QT Webengine complicates everything. Unless Lars' recollection leads to a solution, I'll probably just break down and move PMMail to %UNIXROOT% and delete the drive letter when I need to see HTML emails (usually for paying bills)...
Regards,
-
Thanks Dave - it's working well here!
There is a long standing bug in Dooble on OS/2 where if you try to open an HTML file, it always says 'Your file couldn't be accessed' even though you just clicked on it. However, if that file is on your %UNIXROOT% drive (say C:), and you remove 'C:' from the address bar with that file name on it, the file is displayed. If it is not on the %UNIXROOT% drive, removing, say 'D:' does not help and can not be displayed.
The implication is the code is using a Linux standard to find the file (no drive letters) so it works this way only on the %UNIXROOT% drive. But the Windows version of Dooble does use drive letters and it does work, so it seems there must be a code path available to use drive letters when displaying files if needed.
Are you familiar with this? Has it been looked at in the past? The reason it is important to me is I would like to use Dooble to display e-mail messages from PMMail, but it doesn't work because PMMail is not on %UNIXROOT% so even removing the drive letter doesn't help in that case. Seems like there should be a straight forward solution to this, if the proper code was identified...
Regards,
I vaguely remember that Dmitry already had a fix in place that went into a test version of one of the Qt5 DLLs. I just cannot remember which one that was ...
Thanks for the tip.
There is: https://github.com/bitwiseworks/qtwebengine-chromium-os2/issues/50
&
https://github.com/bitwiseworks/qtwebengine-chromium-os2/commit/6d53f8735fc37460d217f6d641eae585960c1e53
This may have been applied by Dmitry after I created my diffs... I certainly don't have it in my branch...
-
I found it. It is an updated version of qt5webc.dll which is part of the QtWebEngine RPM.
With this updated version, Dooble is able to display local files, regardless on what drive they are located on.
Something like:
file:///E:/CONFIG.SYS
will display in the browser.
{0}[d:\usr\lib] dir qt5webc.dll*
8.09.22 22.43 271.973.910 0 Qt5WebC.dll
25.09.21 19.47 92.191.016 0 Qt5WebC.dll.bak
8.09.22 22.43 271.973.910 0 Qt5WebC.dll.new
-
Thanks Dave - it's working well here!
There is a long standing bug in Dooble on OS/2 where if you try to open an HTML file, it always says 'Your file couldn't be accessed' even though you just clicked on it. However, if that file is on your %UNIXROOT% drive (say C:), and you remove 'C:' from the address bar with that file name on it, the file is displayed. If it is not on the %UNIXROOT% drive, removing, say 'D:' does not help and can not be displayed.
The implication is the code is using a Linux standard to find the file (no drive letters) so it works this way only on the %UNIXROOT% drive. But the Windows version of Dooble does use drive letters and it does work, so it seems there must be a code path available to use drive letters when displaying files if needed.
Are you familiar with this? Has it been looked at in the past? The reason it is important to me is I would like to use Dooble to display e-mail messages from PMMail, but it doesn't work because PMMail is not on %UNIXROOT% so even removing the drive letter doesn't help in that case. Seems like there should be a straight forward solution to this, if the proper code was identified...
Regards,
I vaguely remember that Dmitry already had a fix in place that went into a test version of one of the Qt5 DLLs. I just cannot remember which one that was ...
Thanks for the tip.
There is: https://github.com/bitwiseworks/qtwebengine-chromium-os2/issues/50
&
https://github.com/bitwiseworks/qtwebengine-chromium-os2/commit/6d53f8735fc37460d217f6d641eae585960c1e53
This may have been applied by Dmitry after I created my diffs... I certainly don't have it in my branch...
Yep, that's the fix.
-
<sigh> [listing of woes] Why is everything so hard?
In Ancient Times folk would have said something like, "God is testing you for a Great Task, so go with it." These days, dunno. Maybe you're due to have one of those life-rebooting Road To Damascus Warpstock experiences in due course.
OK it had been a while since I'd built the Qt 6.2 based browser. Turns out that I had some remnants of qt 6.2.8 code in there (which is based on a chromium version what we can't yet build) left over.
Hopefully, I'm on the path to being able to build an updated DLL again.... and I'll include the url fixes.
On a positive note, whilst investigating a build break, I think I fixed a problem generating filename.js.compressed caused by brotli.exe not using binary mode on stdout. Time will tell, that may allow me to revert some hacks :P
-
Hi Lars
Where is the updated Qt5WebC.dll available?
Thanks
Pete
-
Hi Lars
Where is the updated Qt5WebC.dll available?
Thanks
Pete
Although I am not Lars: http://rpm.netlabs.org/test/qw.7z
(as mentioned by Paul in https://github.com/bitwiseworks/qtwebengine-chromium-os2/issues/50)
-
Hi Tom
Thanks for the link but it seems rpm.netlabs is not working...
Regards
Pete
-
Hi Tom
Thanks for the link but it seems rpm.netlabs is not working...
Regards
Pete
I just downloaded it fine besides taking a few seconds to start.
-
Thanks for remembering Lars, and thanks Tom for the link! It does indeed work with the QT5 version of Dooble, so don't need to be moving things around - great! The file is gigantic - I wonder if it could be Lxlite'd? Here's hoping Paul can add this to the QT6 version too...
Regards,
-
Thanks for remembering Lars, and thanks Tom for the link! It does indeed work with the QT5 version of Dooble, so don't need to be moving things around - great! The file is gigantic - I wonder if it could be Lxlite'd? Here's hoping Paul can add this to the QT6 version too...
Regards,
It was a test version, so probably contains debug information. That could explain the large size. Rebuilding without debug information should take care of that.
-
Hi All
Could not download this file with Seamonkey or Dooble.
I experimented a little and found I could download the file with both browsers as long as I changed the url to
https://rpm.netlabs.org/test/qw.7z
Regards
Pete
-
Thanks for remembering Lars, and thanks Tom for the link! It does indeed work with the QT5 version of Dooble, so don't need to be moving things around - great! The file is gigantic - I wonder if it could be Lxlite'd? Here's hoping Paul can add this to the QT6 version too...
Regards,
Should be able to lxlite it. eg,
H:\tmp>lxlite Qt5WebC.dll
┌[ lxLite ]───────────────────────────────────┬[ Version 1.3.9 ]┐
├ Copyright 1996,97 by FRIENDS software ├ All rights ┤
├ Copyright 2001,03 by Max Alekseyev ├ reserved ┤
├ Copyright 2008-10 by OS/4 team ├ ┤
├ Copyright 2011 by Steven H. Levine ├ ┤
├ Copyright 2017-23 by bww bitwise works GmbH └─────────────────┘
├ Qt5WebC.dll initial: 271973910 final: 113291452 gain: 58.4%
├┤Total gain: 158682458 bytes
Still big but smaller.
-
Qt5WebC.dll is large because it's a test build that includes HLL debug data. If you lxlite the DLL, the debug data will be removed and you will not get anything resembling a useful exceptq report. If you are not going to report defects, this will not matter.
-
Hi,
Using Dooble 2024/01/25 (QT5)
I'm unable to go forward as soon I'm on following web page. High cpus etc...
https://www.denafrips.eu/shop
Is it the same with QT6 ?
Any idea about what's happening ?
Regards
-
Hi Rémy,
That page seems to work OK here - though I am using a virtual box with only 1 CPU to run ArcaOS. Also have the blocked domain list installed to avoid ads. It does seem very slow to load, but I don't see a high CPU load. Maybe try Dave's latest 2024/08/20 version (link earlier in the thread) and see if that helps.
Regards,
-
Here's hoping Paul can add this to the QT6 version too...
It'll happen. I fixed my build issues, currently at [1482/3105] so ~1600 source files left to compile from the initial ~25,600. Patches are also in place to support drive letters in the URL bar. Hopefully some time later today assuming no unforeseen issues.
-
Hi,
Using Dooble 2024/01/25 (QT5)
I'm unable to go forward as soon I'm on following web page. High cpus etc...
https://www.denafrips.eu/shop
Is it the same with QT6 ?
Any idea about what's happening ?
Regards
Loaded fine here with the Qt6 browser, used a lot of CPU loading and then 1 core at about 6% CPU. I also have the blocked domains list loaded as well as a large hosts file, so no ads. Ads can be hit and miss, some are horrible for CPU and security.
I should package up the latest block domains list, IIRC it has been updated.
-
Hi Remy
I'm using this qt5 dooble
21-02-24 3:46p 3215039 342 Dooble.exe
available from ftp://dry@ftp.os2voice.org/Dooble_21_02_2024.zip
Also using the updated qt5webc.dll mentioned in this discussion.
No problems loading/displaying https://www.denafrips.eu/shop - no high cpu load.
Regards
Pete
-
Here's the updated blocked and filter texts. I simply zipped up the Data directory in the source so it also includes an example jar and a couple of files that may be Mac specific.
I also use StevenBlack host file, https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts (https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts), it is almost 5MB. Some say not a good idea using such a large host file on our platform but it seems to work fine here. Much simpler to route ad requests to 0.0.0.0.
-
https://smedley.id.au/tmp/qt6weben-6.2.6-20240825.zip has the rebuilt qt6web*.dll. These should be unzipped over the top of the ones from the last Qt 6.2.6 drop. Not tested locally.
EDit: something like:
file:///c:/config.sys works
but
file:///c:\config.sys doesn't work
-
Thanks Paul, seems you're right about the directory separators. Even file:///c:\\config.sys doesn't work.
The weird thing is I was experimenting trying to get localization to work and the error I got is, (using W: instead of C:)
Die Website ist nicht erreichbarDie Webseite unter file:///W:/%5C%5CCONFIG.SYS ist eventuell vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.
ERR_INVALID_URL
Localization seems broken as well as the rest of the browser is in English, probably American English.
-
does file:///c:\config.sys work with the qt5 build? If so, I'll examine the changes more closely...
My changes are at https://github.com/psmedley/qt6-webengine-os2/commit/0e53634c9674d1520049ebba82dc8d0d463021dd
-
Paul,
file:///c:\config.sys does not work on QT5. I haven't seen that happen when opening files from dialogs, so I don't think it is a big problem. Thanks for the new QT6 libs - I'll give them a try now...
Regards,
-
Hi,
Using Dooble 2024/01/25 (QT5)
I'm unable to go forward as soon I'm on following web page. High cpus etc...
https://www.denafrips.eu/shop
Is it the same with QT6 ?
Any idea about what's happening ?
Regards
Loaded fine here with the Qt6 browser, used a lot of CPU loading and then 1 core at about 6% CPU. I also have the blocked domains list loaded as well as a large hosts file, so no ads. Ads can be hit and miss, some are horrible for CPU and security.
I should package up the latest block domains list, IIRC it has been updated.
Are you realy able to use the view detail and add cart button (both are working under windows) ?
-
Using the Qt6 browser, most everything seems to work though I do have to maximize the browser. I made it to the checkout where you enter all your info.
Oh the Window title itself doesn't handle the unicode, OS/2 limitation and it keeps flashing you have one new message.
Remember that the Qt6 Webengine is based on a newer Chromium then the Qt5 one, Chrome 94. I'm mostly using the Qt6 build of Dooble as it displays more pages then the Qt5 build.
-
Paul,
The new QT6 libs seem to work great. Maybe just confirmation bias, but also seem to make the QT6 Dooble more stable with complicated javascript sites (like news websites). One thing I still see is playing videos will eventually hang the browser and/or the system. If playing videos is kept to a minimum, everything stays stable. Thanks!
Regards,
-
Using the Qt6 browser, most everything seems to work though I do have to maximize the browser. I made it to the checkout where you enter all your info.
Oh the Window title itself doesn't handle the unicode, OS/2 limitation and it keeps flashing you have one new message.
Remember that the Qt6 Webengine is based on a newer Chromium then the Qt5 one, Chrome 94. I'm mostly using the Qt6 build of Dooble as it displays more pages then the Qt5 build.
Well, going to give a try to QT6....
Where are all more stable download files (QT + Dooble) ?
I found: https://www.os2world.com/forum/index.php/topic,3252.0.html but it looks to be old !
-
The core DLLs in post 1 of that thread are still current (November 2023).
That build is still current, but to support drive letters in the urlbar, needs the updated DLLs from yesterday.
-
The core DLLs in post 1 of that thread are still current (November 2023).
That build is still current, but to support drive letters in the urlbar, needs the updated DLLs from yesterday.
Sure you haven't lost track? Seems I'm running the build referenced in https://www.os2world.com/forum/index.php/topic,3182.msg44371.html#msg44371 (https://www.os2world.com/forum/index.php/topic,3182.msg44371.html#msg44371).
Perhaps I've lost track.
L:\qt6-6.2.x\lib>bldlevel Qt6Core.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#cmake build system:6.2.8#@##1## 18 May 2024 09:58:11 ARCAOS-803C4C0::::0::@@Core
Vendor: cmake build system
Revision: 6.02.8
Date/Time: 18 May 2024 09:58:11
Build Machine: ARCAOS-803C4C0
ASD Feature ID: 4C0
File Version: 6.2
Description: Core
-
Yeah that will be the 6.2.8 libs with the exception of qtwebengine that's still at 6.2.6. I guess I could/should package up a build wih those binaries.
Given there is now also https://lists.qt-project.org/pipermail/announce/2024-July/000505.html I guess I could update the core libs (minus qtwebengine) to 6.2.9.
-
Hi Dave,
Thanks again for your nice work. I my case I would like to have the German language available.
Greetings, Mike
Here you go for testing purposes. Let us know if you can get them to work. Alex says that the %LANG% variable is the usual way for Qt apps to find their locale. See the included readme from upstream. Not sure if drive letters will work or which path separator to use in DOOBLE_TRANSLATIONS_PATH
Fount today time to test the new dooble with German language using Pauls qt6-6.2.6-os2-20231109 together with his qt6weben-6.2.6-20240825.
I just used the profile from my QT5 dooble and everything worked well so far.
Thanks for the nice work to you and Paul.
Greetings from Potsdam / Germany,
Mike
-
I just installed QT 6.2.8 + latest webengine 6.26 + dooble qt6
I had to add latest ffmpeg-cromium as well vpx8
My first return is that it is faster then the QT5 builds, it uses less cpus too (big drop in cpu utilization)
Some web pages have a better rendering
Some issues found
(note: dictionnaries added and found)
a. Dooble title windows may display invalid characters! (added same duckduckgo main page under Dooble QT5)
b. Chrome user agent isn't correctly indentified by web sites (this works under dooble qt5 after setting a version above 60) - test done using whatsapp online site
c. site page denafrips.eu\shop is better displayed but wasn't able to use the add button to order product nor the view button and if trying several times, my system hung
May be this are known restriction of dooble or some code debug could resolve this ?
Regards
Rémy
-
Anything can be fixed, it's a matter of time. The qtwebengine codebase is HUGE.... and takes a long time to build... and right now, I'm the only one who seems to be able to build it...
-
Anything can be fixed, it's a matter of time. The qtwebengine codebase is HUGE.... and takes a long time to build... and right now, I'm the only one who seems to be able to build it...
The work you do is incredible and great (thanks a lot)
About Dooble title set according web site, it looks that under Dooble it has wrong chars but it is translated into ? char. (see part of screen copy)
May be the Chrome user agent can be corrected and have a good result like under Dooble QT5.
With these updates, I don't see why use QT5 build anymore...
Note: I'll check if these issues are same using a previous qtwebengine build...
-
Some of these problems are still due to using an old version of Chrome. Some sites only support the latest and the latest minus one and even the newest Firefox has problems, basically bad web authoring.
The title bar problem is that OS/2 doesn't support Unicode in things like window titles. Code could be added to convert the Unicode to which ever codepage the user is using. As Paul says, just finding the code to be extended is hard and there are better things to focus on.
The user agent could be a problem with the web sites parsing of it, previously we had problems with Firefox and sites serving up a mobile version as they have no idea what OS/2 is. Here you can experiment with user agents.
The other problem is Dooble has a tendency to freeze when playing some videos, don't try Youtube
It's also a good idea to regularly back up the profile, it seems to get corrupted sometimes when the system freezes.
-
Some of these problems are still due to using an old version of Chrome. Some sites only support the latest and the latest minus one and even the newest Firefox has problems, basically bad web authoring.
The title bar problem is that OS/2 doesn't support Unicode in things like window titles. Code could be added to convert the Unicode to which ever codepage the user is using. As Paul says, just finding the code to be extended is hard and there are better things to focus on.
The user agent could be a problem with the web sites parsing of it, previously we had problems with Firefox and sites serving up a mobile version as they have no idea what OS/2 is. Here you can experiment with user agents.
The other problem is Dooble has a tendency to freeze when playing some videos, don't try Youtube
It's also a good idea to regularly back up the profile, it seems to get corrupted sometimes when the system freezes.
Thanks.
About user agent, changing it under QT5 works well using the same whatsapp site.
I also found following errors:
[111:1:0826/232724.456000:ERROR:system_network_context_manager.cpp(299)] Cannot
use V8 Proxy resolver in single process mode.
[111:1:0826/232724.481000:ERROR:system_network_context_manager.cpp(299)] Cannot
use V8 Proxy resolver in single process mode.
js: Error with Permissions-Policy header: Unrecognized feature: 'interest-cohort
'.
js: Error with Permissions-Policy header: Unrecognized feature: 'interest-cohort
'.
-
Yea, we pretty well have to use single process mode due to limitations with our operating system and some things don't work, another one is private windows.
The JavaScript errors are likely due to the old version of Chrome.
-
Other things I found:
Trying to use the google translate option, the processes link is set incorrectly.
Original link:
https://www.os2world.com/cms/
The issued link for google !
https://www-os2world-com.translate.goog//cms/?_x_tr_sl=auto&.........
A duplicate // before cms
-
Other things I found:
Trying to use the google translate option, the processes link is set incorrectly.
Original link:
https://www.os2world.com/cms/
The issued link for google !
https://www-os2world-com.translate.goog//cms/?_x_tr_sl=auto&.........
A duplicate // before cms
Hmm, this did work, see the original posted picture referenced here, https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660 (https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660) the picture clearly shows a double // and working.
It is easy enough to remove the / It needs more testing, so here is a test build if you want to put it through its paces.
-
Tested Translate on Linux Mint, same problem with the double //
-
Perhaps it is only a problem with some languages, or translating from English to English. The example in the ticket image, https://baotanglichsu.vn/vi (https://baotanglichsu.vn/vi) translates fine to https://baotanglichsu-vn.translate.goog//vi?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp (https://baotanglichsu-vn.translate.goog//vi?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp) which even with the // displays fine.
-
b. Chrome user agent isn't correctly indentified by web sites (this works under dooble qt5 after setting a version above 60) - test done using whatsapp online site
Are you able to post the results from dooble with qt5 and qt6 of https://www.whatismybrowser.com/detect/what-is-my-user-agent/
Ideally if you can check with simplebrowser.exe as well just to make sure it's not dooble futzing with the user agent...
dooble-qt6 reports: "Mozilla/5.0 (OS/2; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.2.6 Chrome/94.0.4606.126 Safari/537.36 Dooble/2024.08.20"
simplebrowser-qt6 reports: "Mozilla/5.0 (Unknown; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.2.6 Chrome/94.0.4606.126 Safari/537.36"
dooble-qt5 reports: "Mozilla/5.0 (Unknown; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2 Chrome/83.0.4103.122 Safari/537.36"
I must have an old dooble-qt5 installed that pre-dates: https://github.com/bitwiseworks/dooble-os2/commit/d03b9359c7f0816a7231f4adc03c25ba6c1a331f
Maybe I misunderstand the problem - are you saying you are OVERRIDING the user agent, and this isn't working?
-
https://smedley.id.au/tmp/qt6-6.2.9-qtwebengine-6.2.6-os2-20240827.zip updated, useragent in simplebrowser is now OS/2; not Unknown :)
-
Other things I found:
Trying to use the google translate option, the processes link is set incorrectly.
Original link:
https://www.os2world.com/cms/
The issued link for google !
https://www-os2world-com.translate.goog//cms/?_x_tr_sl=auto&.........
A duplicate // before cms
Hmm, this did work, see the original posted picture referenced here, https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660 (https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660) the picture clearly shows a double // and working.
It is easy enough to remove the / It needs more testing, so here is a test build if you want to put it through its paces.
Hi Dave,
Yes, the double // is now corrected and the translated page is now well displayed ;)
-
b. Chrome user agent isn't correctly indentified by web sites (this works under dooble qt5 after setting a version above 60) - test done using whatsapp online site
Are you able to post the results from dooble with qt5 and qt6 of https://www.whatismybrowser.com/detect/what-is-my-user-agent/
Ideally if you can check with simplebrowser.exe as well just to make sure it's not dooble futzing with the user agent...
dooble-qt6 reports: "Mozilla/5.0 (OS/2; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.2.6 Chrome/94.0.4606.126 Safari/537.36 Dooble/2024.08.20"
simplebrowser-qt6 reports: "Mozilla/5.0 (Unknown; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.2.6 Chrome/94.0.4606.126 Safari/537.36"
dooble-qt5 reports: "Mozilla/5.0 (Unknown; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2 Chrome/83.0.4103.122 Safari/537.36"
I must have an old dooble-qt5 installed that pre-dates: https://github.com/bitwiseworks/dooble-os2/commit/d03b9359c7f0816a7231f4adc03c25ba6c1a331f
Maybe I misunderstand the problem - are you saying you are OVERRIDING the user agent, and this isn't working?
Here a few screenshots about results.
Under QT5
whatismybrowser doesn't show the new Chrome version of 62....value but Whatsapp link does !
-
b. Chrome user agent isn't correctly indentified by web sites (this works under dooble qt5 after setting a version above 60) - test done using whatsapp online site
Are you able to post the results from dooble with qt5 and qt6 of https://www.whatismybrowser.com/detect/what-is-my-user-agent/
Ideally if you can check with simplebrowser.exe as well just to make sure it's not dooble futzing with the user agent...
dooble-qt6 reports: "Mozilla/5.0 (OS/2; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.2.6 Chrome/94.0.4606.126 Safari/537.36 Dooble/2024.08.20"
simplebrowser-qt6 reports: "Mozilla/5.0 (Unknown; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.2.6 Chrome/94.0.4606.126 Safari/537.36"
dooble-qt5 reports: "Mozilla/5.0 (Unknown; OS/2 i386) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2 Chrome/83.0.4103.122 Safari/537.36"
I must have an old dooble-qt5 installed that pre-dates: https://github.com/bitwiseworks/dooble-os2/commit/d03b9359c7f0816a7231f4adc03c25ba6c1a331f
Maybe I misunderstand the problem - are you saying you are OVERRIDING the user agent, and this isn't working?
Here a few screenshots about results.
Under QT6
note: Tried to set chrome to a version 100 - whatsmybrowser shows the value but whatsapp always request chrome to be at 60+ to work !
It is easy to test using whatsapp link https://web.whatsapp.com/
Now, going to install and try 6.2.9 new package ;)
-
Now under QT6.2.9 (one more nice build) with its 6.2.6 webengine + Latest Dave's Dooble build.
- Problem about window title taken from the website title could have invalid chars (e.g. duckduckgo.com link) - no invalid chars under QT5
- whatsimybrowser no more shows unknown for OS2 and shows all values set under setting but....
- Whatsapp link always complains and request to use chrome above 60 ! (this message disapears under QT5 when changing chrome from 84 to 62 under setting.
-
Hi Paul!
I used https://useragent.wcode.net/en/ user/agent parser to check user agent and It show that it isn't correct.
It display Browser Dooble and Chrome version as Browser engine version ! incorrect.
(under QT5, Browser Chrome and Browser engine version = chrome version = ok)
- I removed the Dooble user/agent from the setting string and than, it displayed QTwebengine !
- I removed QTwebengine too and now it works, whatsapp start ....
I did a check removing QTwebengine only but not enough to resolve the problem.
To correct user agent detection, have to remove the qtwebengine and dooble from user agent setting (QT5 doesn't have them)
Regards
-
Hi !
qtwebengine_dictionaries path hasn't changed under 6.2.9 but !
I have a message about not accessed en_GB.bdic while this file is available, same with all *.bdic > latest Dooble build
Note: under build 6.2.9, doing a nperf test after running a few seconds (nearly 50% of the full test) receive speed test, dooble closes (crash)
Under QT5, I can run one full run and when starting a run a second time, it works until a system hung
-
Other things I found:
Trying to use the google translate option, the processes link is set incorrectly.
Original link:
https://www.os2world.com/cms/
The issued link for google !
https://www-os2world-com.translate.goog//cms/?_x_tr_sl=auto&.........
A duplicate // before cms
Hmm, this did work, see the original posted picture referenced here, https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660 (https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660) the picture clearly shows a double // and working.
It is easy enough to remove the / It needs more testing, so here is a test build if you want to put it through its paces.
Hi Dave,
This build corrects the double // for the google translate tool.
But, dictionaries aren't found (canot be accessed *.bdic) and the message when renaming the dictionary path start with:
"Please read K:/work/dooble-dry/source/...." this is your disk path ;)
Something got wrong into this Dooble build.
Back to previous build, message is correct and after correcting the path name, dictionaries are found
:)
-
I'm going back from 6.2.9 to 6.2.8 which seems to be better.
Under 6.2.8, https://web.whatsapp.com is displayed, than medium cpu load and than the QR code is displayed to authorize whatsapp sync with mobile and conversations can start.
Under 6.2.9, https://web.whatsapp.com is displayed, than higher and longer cpu load, no QR code displayed and ends with a system hung and have to power off/on my tower computer.
note: into a trap of 6.2.8 build, I found that some loaded dlls were back level !
I have "Apache OpenOffice quick start", this one loads dll from under Apache OpenOffice sub dir program with its *.dll where some are back level compared to newest under \usr\lib like (found be used into the trap): LIBCX0.DLL, LIBCN0.DLL while Z1.dll is at same level.
I give a new try on 6.2.9 after remove of apache quick start from startup and renamed libc*.dll from under apache sub dir to use newest from under \usr\lib
now, https://web.whatsapp.com works like under 6.2.8 ! I'll continue to use 6.2.9
List of commun DLLs found under my \usr\lib (ArcaOS 5.1 latest updated package) and those under Apache OpenOffice (sub dir program)
curl7.dl_
gcc1.dl_
gcc446.dl_
gcc473.dl_
hunspel0.dl_
libcn0.dl_
libcx0.dl_
libxml2.dl_
mmap.dl_
UClip.dl_
z.dl_
z1.dl_
-
Other things I found:
Trying to use the google translate option, the processes link is set incorrectly.
Original link:
https://www.os2world.com/cms/
The issued link for google !
https://www-os2world-com.translate.goog//cms/?_x_tr_sl=auto&.........
A duplicate // before cms
Hmm, this did work, see the original posted picture referenced here, https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660 (https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660) the picture clearly shows a double // and working.
It is easy enough to remove the / It needs more testing, so here is a test build if you want to put it through its paces.
Hi Dave,
This build corrects the double // for the google translate tool.
But, dictionaries aren't found (canot be accessed *.bdic) and the message when renaming the dictionary path start with:
"Please read K:/work/dooble-dry/source/...." this is your disk path ;)
Something got wrong into this Dooble build.
Back to previous build, message is correct and after correcting the path name, dictionaries are found
:)
Did the message say where in the source to read? Quickly looking, I can't find it.
set qtwebengine_dictionaries= does work here with the full path name including drive letter and using / instead of \ for directory separator.
-
Hi Dave
Silly question but where to get the dictionaries?
Regards
Pete
-
https://github.com/textbrowser/dooble/tree/master/Dictionaries ?
-
Other things I found:
Trying to use the google translate option, the processes link is set incorrectly.
Original link:
https://www.os2world.com/cms/
The issued link for google !
https://www-os2world-com.translate.goog//cms/?_x_tr_sl=auto&.........
A duplicate // before cms
Hmm, this did work, see the original posted picture referenced here, https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660 (https://github.com/textbrowser/dooble/issues/200#issuecomment-1819629660) the picture clearly shows a double // and working.
It is easy enough to remove the / It needs more testing, so here is a test build if you want to put it through its paces.
Hi Dave,
This build corrects the double // for the google translate tool.
But, dictionaries aren't found (canot be accessed *.bdic) and the message when renaming the dictionary path start with:
"Please read K:/work/dooble-dry/source/...." this is your disk path ;)
Something got wrong into this Dooble build.
Back to previous build, message is correct and after correcting the path name, dictionaries are found
:)
Did the message say where in the source to read? Quickly looking, I can't find it.
set qtwebengine_dictionaries= does work here with the full path name including drive letter and using / instead of \ for directory separator.
Here are screenshots taken with the very latest dooble (with corrected //) and the previous one.
Taken in both following cases.
- I renamed the dictionaries path to have it unavailable
- Correct dictionaries path with included dictionaries
Dooble QT6 - with corrected google translate slash, missing dictionaries path.jpg
Dooble QT6 - with corrected google translate slash, dictionaries path exist.jpg
Dooble QT6 - with missing dictionaries path.jpg
Dooble QT6 - with the correct dictionaries path.jpg
note: I just switched between both Dooble under same start path.
-
I did a check removing QTwebengine only but not enough to resolve the problem.
To correct user agent detection, have to remove the qtwebengine and dooble from user agent setting (QT5 doesn't have them)
FWIW - dooble on Ubuntu behaves the same way with https://web.whatsapp.com/ - seems to be a whatsapp bug with how they interpret the useragent.
-
I did a check removing QTwebengine only but not enough to resolve the problem.
To correct user agent detection, have to remove the qtwebengine and dooble from user agent setting (QT5 doesn't have them)
FWIW - dooble on Ubuntu behaves the same way with https://web.whatsapp.com/ - seems to be a whatsapp bug with how they interpret the useragent.
I don't know,
Found other sites wrongly identifying browser and its version with this settings
I have a bypass, remove qtwebengine and dooble user agents from the line
Added how it is seen when changing user agents (Dooble isn't supported by whatsapp while Chome is)
-
Hi Remy, seems there's been a patch applied upstream that broke the dictionary search, notice the 2 versions refer to different addresses. Looking quickly with git blame, all I found was a commit that created better error reporting.
Later I'll bisect the tree to try to find the commit that broke things.
-
Hi David, seems really the dictionaries should be packaged during the build, at least the other day when I built Dooble on Linux Mint, that happened. Not sure if a bug or missing directive in the dooble.pro file.
I do have this howto, from Bitwise? or did I write it and forgot?
Create x:\qt6\qtwebengine_dictionaries
copy dictionary files such as en_CA.aff and en_CA.dic from @uixroot/usr/share/myspell to the above.
From x:\qt6\qtwebengine_dictionaries, run qwebengine_convert_dict ./en_CA ./en_CA.bdic so something like
[L:\qt6\bin\qtwebengine_dictionaries]qwebengine_convert_dict ./en_CA.dic ./en_CA.bdic
./en_CA.dic_delta not found.
Reading ./en_CA.aff
Reading ./en_CA.dic
Serializing...
Verifying...
Writing ./en_CA.bdic
Success. Dictionary converted.
Of course you have to install the language you desire, hunspell-fr for French for example.
-
About UA (User Agent) detection. A lot of sites seem to have crappy UA detection. Ideally they shouldn't even care about the UA, rather detecting browser features and adjusting the page or rejecting the browser based on the detection.
Instead they seem to detect the browser, compare to a list and fail when a browser or Operating System appears that is not in the list. I monitor the SeaMonkey newsgroup and UA's often come up. Which version of Firefox to advertise in SeaMonkey's UA, whether to mention Firefox are common topics. They've even added, in about:settings, the capability to vary the UA depending on site.
I still use SeaMonkey mostly and have the UA switcher extension installed. There are sites where I actually use the Dooble UA string to get the page to display the page.
Basically, using uncommon browsers breaks the UA detection on too many pages, so have to change the UA
-
Here's the commit that broke finding the dictionaries when installed as qtwebengine_dictionaries as a child directory under the directory where the dooble binary resides.
I can't quickly see the problem, have to sleep on it. I do notice that dooble.sh, the Linux wrapper script has various export QTWEBENGINE_DICTIONARIES_PATH= added. Perhaps we should just do similar rather then getting further from upstream by reverting this commit or otherwise changing things.
From 02958934b6771efdebbb9dfdc8d77e3d7018c2c2 Mon Sep 17 00:00:00 2001
From: textbrowser <textbrowser@gmail.com>
Date: Fri, 26 Apr 2024 18:35:35 -0400
Subject: [PATCH] Improved error messages.
---
Source/dooble_settings.cc | 22 ++++++++++++++--------
dooble.sh | 4 ++++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/Source/dooble_settings.cc b/Source/dooble_settings.cc
index a84e9f76..0ff17f49 100644
--- a/Source/dooble_settings.cc
+++ b/Source/dooble_settings.cc
@@ -2304,21 +2304,22 @@ void dooble_settings::show_panel(dooble_settings::Panels panel)
void dooble_settings::show_qtwebengine_dictionaries_warning_label(void)
{
- m_ui.qtwebengine_dictionaries_warning_label->setText
- (tr("<b>Warning!</b> "
- "The directory qtwebengine_dictionaries cannot be accessed. "
- "Dooble searched QTWEBENGINE_DICTIONARIES_PATH and the relative "
- "qtwebengine_dictionaries directories. "
- "Please read %1, line %2.").arg(__FILE__).arg(__LINE__));
m_ui.qtwebengine_dictionaries_warning_label->setVisible(false);
auto bytes(qgetenv("QTWEBENGINE_DICTIONARIES_PATH"));
if(bytes.trimmed().isEmpty())
{
- bytes = "qtwebengine_dictionaries";
+ auto directory
+ (QDir::currentPath() + QDir::separator() + "qtwebengine_dictionaries");
- if(!QFileInfo(bytes).isReadable())
+ m_ui.qtwebengine_dictionaries_warning_label->setText
+ (tr("<b>Warning!</b> "
+ "The directory qtwebengine_dictionaries cannot be accessed. "
+ "Dooble searched %1. Please read %2, line %3.").
+ arg(directory).arg(__FILE__).arg(__LINE__));
+
+ if(!QFileInfo(directory).isReadable())
{
m_ui.qtwebengine_dictionaries_warning_label->setVisible(true);
return;
@@ -2326,6 +2327,11 @@ void dooble_settings::show_qtwebengine_dictionaries_warning_label(void)
}
else if(!QFileInfo(bytes).isReadable())
{
+ m_ui.qtwebengine_dictionaries_warning_label->setText
+ (tr("<b>Warning!</b> "
+ "The directory qtwebengine_dictionaries cannot be accessed. "
+ "Dooble searched %1. Please read %2, line %3.").
+ arg(bytes.constData()).arg(__FILE__).arg(__LINE__));
m_ui.qtwebengine_dictionaries_warning_label->setVisible(true);
return;
}
diff --git a/dooble.sh b/dooble.sh
index dd7f8d02..ac5d06a8 100755
--- a/dooble.sh
+++ b/dooble.sh
@@ -28,6 +28,7 @@ export QT_X11_NO_MITSHM=1
if [ -r ./Dooble ] && [ -x ./Dooble ]
then
echo "Launching a local Dooble."
+ export QTWEBENGINE_DICTIONARIES_PATH=qtwebengine_dictionaries
if [ -r ./Lib ]
then
@@ -46,6 +47,7 @@ then
echo "Launching an official Dooble."
export DOOBLE_TRANSLATIONS_PATH=/opt/dooble/Translations
export LD_LIBRARY_PATH=/opt/dooble/Lib
+ export QTWEBENGINE_DICTIONARIES_PATH=/opt/dooble/qtwebengine_dictionaries
export QT_PLUGIN_PATH=/opt/dooble/plugins
cd /opt/dooble && exec ./Dooble "$@"
exit $?
@@ -54,6 +56,8 @@ then
echo "Launching an official Dooble."
export DOOBLE_TRANSLATIONS_PATH=/usr/local/dooble/Translations
export LD_LIBRARY_PATH=/usr/local/dooble/Lib
+ export QTWEBENGINE_DICTIONARIES_PATH=/usr/local/dooble/\
+ qtwebengine_dictionaries
export QT_PLUGIN_PATH=/usr/local/dooble/plugins
cd /usr/local/dooble && exec ./Dooble "$@"
exit $?
--
2.30.2
-
Hi All
Having visited https://github.com/textbrowser/dooble/tree/master/Dictionaries I have no idea on how to get these dictionaries.
Are they different to the Dooble_QT5 versions?
Regards
Pete
-
They're the same as the Qt5 dictionaries. To get the ones Paul pointed to means doing a git clone. Easier to get the ones in @unixroot\usr\share\myspell. Either way they need to be converted with qwebengine_convert_dict.exe, either the one in @unixroot\usr\lib\qt5\bin or x:\qt6-6.2.x\bin. See my previous post.
I'd post the dictionaries directory, but zipped it is 35MB's. If you need an individual one, ask.
Actually here's my dictionaries, various en, now removed
Edit: figured out how to automatically create the dictionaries during build, so here's the ones I think we would like to have.
-
Hi Dave
The suggestion of using the files in @unixroot\usr\share\myspell would not work here due to a lack of @unixroot\usr\share\myspell so I pointed set QTWEBENGINE_DICTIONARIES_PATH= to the existing qt5 files which seemed to work.
Have now installed your dictionary package within the qt6 directory tree and reset QTWEBENGINE_DICTIONARIES_PATH= to point to those files.
Thanks
Pete
-
Hi Pete, Hunspell uses the myspell dictionaries and I believe most have hunspell installed, Firefox and Thunderbird require it, SeaMonkey I accidentally used the intree version and then decided to leave it that way.
Anyways the ones I posted are likely more up to date and already converted.
-
Hi Pete, Hunspell uses the myspell dictionaries and I believe most have hunspell installed, Firefox and Thunderbird require it, SeaMonkey I accidentally used the intree version and then decided to leave it that way.
Anyways the ones I posted are likely more up to date and already converted.
https://chromium.googlesource.com/chromium/deps/hunspell/+/9f292621c01a6708cd35416c4482ba5d6881186f/dictionaries ?
-
Hello
Here in Ecuador Whatsapp is used a lot. I also tried with Qt6 and Dooble here.
I changed the agent to a different one so it can load the page, otherwise it asks you to update the browser:
- Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Here on my side is very slow. I was able to link it, it took some time to load my chats, I can see those, but it is very slow here in my VM to be able to chat. It seems it takes a lot of CPU resources. But it is nice to see it loading, I will try to test it on real hardware this weekend.
Thanks for all the efforts of porting Qt6 and Dooble !!!
Regards
-
New build at Github, https://github.com/dryeo/dooble/releases/tag/2024.11.17 (https://github.com/dryeo/dooble/releases/tag/2024.11.17)
Also at ftp://dry@ftp.os2voice.org/dooble-2024.11.17-Qt6.zip (http://ftp://dry@ftp.os2voice.org/dooble-2024.11.17-Qt6.zip)
Edit: Changed ftp link to version. Note that OS2World seems to add http to the ftp link so best just to go to the ftp site to find the release or paste it into your browser.
-
link not responding !
-
Hi, Rémy...
Link works fine here (from the eastern US, at least). Either it was a temporary issue on the server side or something with your end.
-
link not responding !
OS2World seems to add http:// to the link, copy and paste it or go to ftp://dry@ftp.os2voice.org/ to find it.
-
Thanks Dave! Working well here...
Regards,
-
Thanks Dave.
Seems to well work except that my dictionaries are no more found !
QT6 build didn't find the path nor did QT5 build yet !
Where should the qtwebengine_dictionaries be placed now please ?
Thanks
Note: The code page issue on the title bar and a few other places always present.
-
Note: The code page issue on the title bar and a few other places always present.
It would be really nice if someone other than me could try and investigate this.... I only have so much free time....
-
Thanks Dave.
Seems to well work except that my dictionaries are no more found !
QT6 build didn't find the path nor did QT5 build yet !
Where should the qtwebengine_dictionaries be placed now please ?
Thanks
According to the release notes, you should set DOOBLE_DICTIONARIES_DIRECTORY to the absolute path of the dictionaries. Unluckily that seems to be a build time thing.
Looking at the source, need to set QTWEBENGINE_DICTIONARIES_PATH to the dictionaries directory, which does work here. Only tested with using / for a directory separator.
Need to experiment during build to have a better default, perhaps @unixroot\usr\share\myspell where the Hunspell dictionaries are installed, unluckily they're in dic format rather then bdic. Another option might be %HOME%\QTWEBENGINE_DICTIONARIES or such.
-
Note: The code page issue on the title bar and a few other places always present.
It would be really nice if someone other than me could try and investigate this.... I only have so much free time....
I could try comparing to the Qt5 source where it works, unluckily I've lost track of where your source is.
I do have,
https://github.com/psmedley/qt6-declarative-os2
https://github.com/psmedley/qt6-multimedia-os2
https://github.com/psmedley/qt6-os2
https://github.com/psmedley/qt6-webengine-os2
All dated early 2023 with qt6-os2 the latest dated Aug 7, 2023
-
There are more recent sources than aug 23 in the main branch....
-
There are more recent sources than aug 23 in the main branch....
So it is main I should checkout?
-
There are more recent sources than aug 23 in the main branch....
So it is main I should checkout?
Yeah - main = 6.2.x - other branches are 6.3.x, 6.4.x and 6.5.x - current recommended qt6 & webengine builds are 6.2.x off of main.
I'm suspecting some kind of unicode issues in qt6-base-os2 but I could be very wrong...
-
I'm suspecting some kind of unicode issues in qt6-base-os2 but I could be very wrong...
That was my suspicion. I grepped through the Qt5 source for UniUconvToUcs, UniFreeUconvObject and CP850. Only CP850 gave any hits, mostly in libiconv and also in qtbase\src\corelib\codecs\qsimplecodec.cpp which doesn't even exist in Qt6 and doesn't seem relevant.
Thinking about it, Cairo Clock was broken and displaying unicode instead of the correct code page, as soon as it tried to display any umlauts or accents, it froze the WPS. Don't know if trying to display Unicode in the frame would do the same but assume so.
-
I guess it would be libicu or such that does the conversion.
-
I guess it would be libicu or such that does the conversion.
In which case it could be in https://github.com/psmedley/qt6-webengine-os2/tree/main/src/3rdparty/chromium/third_party/icu
-
I guess it would be libicu or such that does the conversion.
In which case it could be in https://github.com/psmedley/qt6-webengine-os2/tree/main/src/3rdparty/chromium/third_party/icu
Qt5's webengine uses the system libicu ver 68. Is there a build option to use the system ICU? Otherwise it might mean applying the system patches to the intree version 69. Seems every ICU update breaks compatibility with the previous release so not sure how hard that would be.
-
IIRC it needs ICU 69 hence the use of the in-tree ICU. pretty sure I applied all the patches from the bww port of ICU68 though - but it's always possible I screwed something up
-
Did you rebuild the ICU data files, or was rebuilding needed? See README.chromium in the icu directory. Other then that, I really don't know much about ICU.
-
Did you rebuild the ICU data files, or was rebuilding needed? See README.chromium in the icu directory. Other then that, I really don't know much about ICU.
I didn't.... hmmm looks like a PITA :(
-
Did you rebuild the ICU data files, or was rebuilding needed? See README.chromium in the icu directory. Other then that, I really don't know much about ICU.
I didn't.... hmmm looks like a PITA :(
OK I forked BWW icu and updated it to 69.1 (the version that chromium in 6.2.x uses) - https://github.com/psmedley/icu-os2
building it now...
Unfortunately the build is stopping with:
make[2]: Leaving directory '/home/psmedley/icu-os2/source/data'
make[1]: *** No rule to make target 'out/tmp/icudata.lst', needed by 'build-local'. Stop.
make[1]: Leaving directory '/home/psmedley/icu-os2/source/data'
-
OK hacked thru this, and rebuilding webengine with system icu...
-
OK hacked thru this, and rebuilding webengine with system icu...
Be nice if it is as simple as fixing libicu, otherwise likely somewhere in the widgets.
-
Remy, how do you have your environment set up to display French in Dooble? Guess I could install a French version of AOS but I failed French in school :(
-
OK hacked thru this, and rebuilding webengine with system icu...
Be nice if it is as simple as fixing libicu, otherwise likely somewhere in the widgets.
Agree it would be nice, however, OS/2 box keeps hanging/not responding trying to rebuild the webengine <sigh>
Sometimes it happens whilst getting close to making Qt6WebEn.dll - now it seems to repeatably hang/die whilst regenerating build files with gn. Have run jfs chkdsk and it shows clean...
Edit: ran cmake with --verbose and fingers crossed, seems to be getting further...
Edit2: got a DLL, but it's still not using system ICU :(
-
Remy, how do you have your environment set up to display French in Dooble? Guess I could install a French version of AOS but I failed French in school :(
Hi Dave,
For translation and dictionnary, I added the corresponding path to have both available.
About the language issue:
COUNTRY=033,C:\OS2\SYSTEM\COUNTRY.SYS
CODEPAGE=850,1004
DEVINFO=KBD,FR189,C:\OS2\KEYBOARD.DCP
SET LANG=fr_FR_EURO
Regards
Rémy
PS: I find the latest QT6 build less stable using same priority parameters then previous buil (had to change a little priority settings)
-
Edit2: got a DLL, but it's still not using system ICU :(
OK with some makefile hackery, to force linking against the system icu in preference to the bundled one - it's now using system ICU. Ran out of time to test, but https://smedley.id.au/tmp/qt6weben-systemicu-20241125.zip has a new qt6weben.dll, along with the needed icu 69.1 DLL's
-
Thanks Paul... I get a 404 'not found' on that link, but figured out it needs the'tmp' directory added so https://smedley.id.au/tmp/qt6weben-systemicu-20241125.zip does work. I'll give it a try later today...
LATER: Tried it and it works fine, but I don't see any difference - still get odd characters in the title bar every once in awhile I don't get with the QT5 version. Paul's website shows it ( https://os2ports.smedley.id.au )- there is a question mark '?' in the QT5 dooble tiitle bar the QT6 version shows 3 strange characters there...
Regards,
-
Interesting, SeaMonkey shows an underline, Dooble_Qt5 a question mark and Dooble_Qt6, as you said, 3 weird characters. The source is,
<title>Unix Ports for OS/2 & ArcaOS – by Paul Smedley</title>
-
https://github.com/dryeo/dooble/releases/tag/2024.11.23 (https://github.com/dryeo/dooble/releases/tag/2024.11.23)
ftp://dry@ftp.os2voice.org/dooble/dooble-2024.11.23-Qt6.zip
-
I'll enable the tests for qtbase and see if maybe there's an issue with text conversion in https://github.com/psmedley/qt6-base-os2/tree/main/src/corelib/text
-
I'll enable the tests for qtbase and see if maybe there's an issue with text conversion in https://github.com/psmedley/qt6-base-os2/tree/main/src/corelib/text
This appears to be a codepage problem: titlebar text is not being handled correctly. See the attached screenshot of Dooble/QT6.
The first line is the source for the <title> tag - it includes an HTML entity for the hyphen.
The second line is the same text when rendered as part of a page - the entity is converted correctly.
The third line is the exact same text you see in the screenshot titlebar - the entity has been converted to UTF8. It is rendered correctly by the page because UTF8 is the native codepage for HTML but not by the titlebar because the titlebar expects CP850.
In short, before setting the titlebar text it must be converted from UTF8 to the current _native_ codepage (which may not be CP850 for some users).
-
The problem seems to be the dash, which is not ascii. See how it displays here,
–
Normal dash,
-
SeaMonkey does display it fine in the text but not in the title bar, where it is an underline. Could it also be a font problem? Or simply the WPS has problems with non-ascii characters in the titlebar? Dooble-Qt5 also fails to correctly display the en dash or whatever it is though it displays a question mark.
Edit: It's U+2013 : EN DASH according to Babelstone.
-
OK, created a basic test page with ÀŽƒ in the title. SeaMonkey and Dooble-Qt5 fail to display Ž with SM showing an underline and Dooble-Qt5 showing a question mark for the missing glyph. Dooble-Qt6 shows garbage. The title bar does seem capable of displaying UTF8 as long as the font has the glyph but something goes wrong with Dooble-Qt6, almost seems like it is translating it to cp850 here.
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Test Page. ÀŽƒ </title>
</head>
<body>
<br>
</body>
</html>
Save as something like test.html and try loading the file.
Looking at the screen shot, you see the glyphs do display in the tab.
-
Thanks.... potentially an issue with toLocal8Bit - https://github.com/psmedley/qt6-base-os2/blob/734fce3e5beabf48094bf3b1db2145fc0279b977/src/plugins/platforms/os2/qos2window.cpp#L810
This calls qt_convert_to_local_8bit() which in qt5 is:
https://github.com/bitwiseworks/qtbase-os2/blob/0a7d641039e9e482cccdeecd4934ac8ec3790eb0/src/corelib/text/qstring.cpp#L5325
& qt6:
https://github.com/psmedley/qt6-base-os2/blob/734fce3e5beabf48094bf3b1db2145fc0279b977/src/corelib/text/qstring.cpp#L5212
-
Thanks Paul... I get a 404 'not found' on that link, but figured out it needs the'tmp' directory added so https://smedley.id.au/tmp/qt6weben-systemicu-20241125.zip does work. I'll give it a try later today...
LATER: Tried it and it works fine, but I don't see any difference - still get odd characters in the title bar every once in awhile I don't get with the QT5 version. Paul's website shows it ( https://os2ports.smedley.id.au )- there is a question mark '?' in the QT5 dooble tiitle bar the QT6 version shows 3 strange characters there...
Regards,
Hi Paul,
When i copy those files to my hd and try to run dooble, i get a not enough mem, when i use the old files all works...
Any idea...
-
Tellie,
You probably need to use 'Highmem' to get the DLL's to load into high memory... from a command prompt like this:
highmem -c qt6weben.dll
Highmem is available from ANPM.
Regards,
-
Hi Dave!
The translate web page option isn't working as it should.
I have a link not working.
https://eike-klima-energie.eu/2024/11/25/geister-wetterstationen-in-grossbritannien-mehr-als-ein-drittel-nicht-existent/
As you can see, you have '-' into the link name, the '-' should be changed to '--' for Google translate but it isn't. Dooble generated link :
https://eike-klima-energie-eu.translate.goog/2024/11/25/geister-wetterstationen-in-grossbritannien-mehr-als-ein-drittel-nicht-existent/?_x_tr_sl=auto&_x_tr_tl=fr&_x_tr_hl=fr&_x_tr_pto=wapp
Google translate generated link which works:
https://eike--klima--energie-eu.translate.goog/2024/11/25/geister-wetterstationen-in-grossbritannien-mehr-als-ein-drittel-nicht-existent/?_x_tr_sl=auto&_x_tr_tl=fr&_x_tr_hl=fr_x_tr_pto=wapp
-
Hi Remy, I see what you mean. Seems to be a problem with up-streams choice on how to implement translations. I'll play some more with changes to the translate URL, might have to raise an issue upstream.
I note that SeaMonkey gets it right.
-
using .toLatin1() instead of .toLocal8Bit() in https://github.com/psmedley/qt6-base-os2/blob/734fce3e5beabf48094bf3b1db2145fc0279b977/src/plugins/platforms/os2/qos2window.cpp#L810 gets rid of the 3 funny characters and changes it to a single ?
Attached updated qos2.dll
Definitely seems like a locale issue, and pretty sure it's within qtbase
-
An other issue (older one)
Suppr key not working (always have to put the cursor after the char to delete and use backward key)
It would be nice been able to have suppr key operational as expected.
Other:
Doing a copy of a text or link (e.g. link from link field).
When doing the past into an editor while Dooble is running works but if Dooble is closed before doing the past, clipboard is put empty and past didn't work (lost of copied field)
Regards
Rémy
-
Tellie,
You probably need to use 'Highmem' to get the DLL's to load into high memory... from a command prompt like this:
highmem -c qt6weben.dll
Highmem is available from ANPM.
Regards,
Thankz David,
Totaly forgotten this :)
-
Thanks.... potentially an issue with toLocal8Bit - https://github.com/psmedley/qt6-base-os2/blob/734fce3e5beabf48094bf3b1db2145fc0279b977/src/plugins/platforms/os2/qos2window.cpp#L810
This calls qt_convert_to_local_8bit() which in qt5 is:
https://github.com/bitwiseworks/qtbase-os2/blob/0a7d641039e9e482cccdeecd4934ac8ec3790eb0/src/corelib/text/qstring.cpp#L5325
& qt6:
https://github.com/psmedley/qt6-base-os2/blob/734fce3e5beabf48094bf3b1db2145fc0279b977/src/corelib/text/qstring.cpp#L5212
Narrowing this down further..... I created a testcase:
#include <iostream>
#include <string>
#include <QDebug>
#include <QString>
int main()
{
QString s = QString::fromUtf8("\u20AC");
qDebug() << s.toLocal8Bit();
qDebug() << s.toLocal8Bit().data();
qDebug() << s.toLatin1();
qDebug() << s.toUtf8();
qDebug() << s.toUtf8().data();
return 0;
}
On Linux, I get:
"\xE2\x82\xAC"
€
"?"
"\xE2\x82\xAC"
€
On OS/2, I get:
"\xE2\x82\xAC"
â¬
"?"
"\xE2\x82\xAC"
â¬
This could be a codepage issue on my box, I have NFI about this stuff. Testcase is at https://smedley.id.au/tmp/test.zip - needs qt6core.dll
-
I get,
[H:\tmp]test
"\xE2\x82\xAC"
Ôé¼
"?"
"\xE2\x82\xAC"
Ôé¼
Remember that the command shell has no knowledge of unicode. At that, I'm not aware of any cmd line utility that does have knowledge of UTF.
BTW, your updated qt6code.dll didn't seem to help here, just changing the glyphs in a wrong way.
-
I have NFI about this stuff.
Let me be immodest and tell you that I _do_ have an idea about this stuff - and a solution.
The basic issue is that the browser's titlebar should be able to correctly display thousands of different characters - just like the browser itself - but that ain't going to happen if the titlebar is using a codepage that's limited to 256 codepoints. Screwing around to get it to display a question mark rather than the 3-byte UTF8 encoding for a typographic dash accomplishes virtually nothing.
The solution is to set the codepage for the browser's primary thread to CP1208, i.e. UTF8, so the titlebar can render the untranslated UTF8 bytestream correctly. The attached screenshots demonstrate this (for the Chinese example, I had to change the titlebar font from WarpSans to one that includes Chinese glyphs).
Using CP1208 is something I would never otherwise recommend because it normally slows PM text handling down to a crawl. However, in the case of Dooble, the titlebar and system menu are the only places in the entire app that PM renders the text itself. In my limited testing, it appeared to have no noticable impact on performance.
Given all this, I would strongly, strongly recommend implementing this fix in Dooble itself and *not* in QT6 since other QT6-based apps may handle their titlebars differently. To do so, add the following code to Dooble early in its processing: probably right after it initializes the QT6 framework and no later than after it creates its first window (the primary thread's message queue has to exist for this to have any effect). This should only be used on the very first thread.
WinSetCp(HMQ_CURRENT, 1208);
FYI... to create my examples, I used my 'CpPal' util to switch the CP to 1208 on the fly. If you have it, set the CP to 1208, then drag from the "Set" icon and drop on the browser.
-
I have NFI about this stuff.
Given all this, I would strongly, strongly recommend implementing this fix in Dooble itself and *not* in QT6 since other QT6-based apps may handle their titlebars differently. To do so, add the following code to Dooble early in its processing: probably right after it initializes the QT6 framework and no later than after it creates its first window (the primary thread's message queue has to exist for this to have any effect). This should only be used on the very first thread.
WinSetCp(HMQ_CURRENT, 1208);
OK, tried putting this just before the splash screen, earlier used
#ifdef Q_OS_OS2
#define INCL_WINCOUNTRY
#include <os2.h>
HMQ hmq;
#endif
Dies with,
K:/work/dooble-dry/Source/dooble_main.cc: In function 'int main(int, char**)':
K:/work/dooble-dry/Source/dooble_main.cc:432:12: error: 'HMQ_CURRENT' was not declared in this scope; did you mean 'FILE_CURRENT'?
432 | WinSetCp(HMQ_CURRENT, 1208);
Found this in pmwin.h,
#define HMQ_CURRENT ((HMQ)1)
which dies with,
K:/work/dooble-dry/Source/dooble_main.cc:55:36: error: use of old-style cast to
'HMQ' {aka 'long unsigned int'} [-Werror=old-style-cast]
55 | #define HMQ_CURRENT ((HMQ)1)
| ^
K:/work/dooble-dry/Source/dooble_main.cc:432:12: note: in expansion of macro 'HM
Q_CURRENT'
432 | WinSetCp(HMQ_CURRENT, 1208);
| ^~~~~~~~~~~
cc1plus.exe: all warnings being treated as errors
How to set this up?
-
I get,
[H:\tmp]test
"\xE2\x82\xAC"
Ôé¼
"?"
"\xE2\x82\xAC"
Ôé¼
Redirecting stderr to a file then loading it in qe with utf8 encoding gives,
"\xE2\x82\xAC"
€
"?"
"\xE2\x82\xAC"
€
[/quote]
-
How to set this up?
OK, if HMQ_CURRENT resolves to the number '1', try plugging in a '1' for now, i.e.: WinSetCp(1, 1208);
(I should know how to do a new-style cast but that bit of knowledge escapes me currently.)
-
Once we get this working, we should patch simplebrowser.exe too - I assume it has the same issue...
-
How to set this up?
OK, if HMQ_CURRENT resolves to the number '1', try plugging in a '1' for now, i.e.: WinSetCp(1, 1208);
(I should know how to do a new-style cast but that bit of knowledge escapes me currently.)
Well, I've tried adding the code in various places that seemed early enough in the process, mostly in dooble_main.cc and even right after QApplication::processEvents(); in dooble.cc and no luck.
Guess going to have to read up on how Qt initializes unless Paul has an idea.
-
I also wonder if it should be in the webengine, which is basically chromium.
-
How to set this up?
OK, if HMQ_CURRENT resolves to the number '1', try plugging in a '1' for now, i.e.: WinSetCp(1, 1208);
(I should know how to do a new-style cast but that bit of knowledge escapes me currently.)
Well, I've tried adding the code in various places that seemed early enough in the process, mostly in dooble_main.cc and even right after QApplication::processEvents(); in dooble.cc and no luck.
Guess going to have to read up on how Qt initializes unless Paul has an idea.
dooble_main.cc was my guess....
-
Well, I've tried adding the code in various places that seemed early enough in the process, mostly in dooble_main.cc and even right after QApplication::processEvents(); in dooble.cc and no luck.
Guess going to have to read up on how Qt initializes unless Paul has an idea.
I'm sorry to see that this isn't the slam-dunk I hoped it would be. After the splash screen and before the main window is created should have worked. I've attached 'cppal030.zip' so you can confirm that changing the codepage manually works for you.
OK... just noticed something odd: using CpPal to drop the new CP on the main part of the window has no effect. I have to release MB2 while over the titlebar to get it to change. I looked at my notes for CpPal and discovered that it requires a bit more hack-ery to get this to work. CpPal has to fake a font-change in the window where you dropped to get it to notice and do an update.
Let's put this on hold for a bit while I figure out how and where to do this stuff. I'm quite certain that once we get the kinks worked out, just a few lines of code will give us a titlebar that isn't filled with question marks and wierdness :)
Meanwhile, Dave, can you give me a URL that points to your dooble_main.cc?
-
Afaik Dave is using the original source, ie https://github.com/textbrowser/dooble/blob/master/Source%2Fdooble_main.cc
-
Looks like he has a fork at https:\\www.github.com\dryeo\dooble
-
Meanwhile, Dave, can you give me a URL that points to your dooble_main.cc?
https://github.com/dryeo/dooble/blob/master/Source/dooble_main.cc (https://github.com/dryeo/dooble/blob/master/Source/dooble_main.cc)
-
Dave / Paul,
OMG! I've been out of the loop too long! It's going to take me a while to figure out the plumbing on this thing.
The goal is to use whatever info is available within Dooble to get back to a window's native handle (hwnd), then use that to trigger an update. All this info is available in 'qos2window.cc' but getting there programmatically looks like it will require a steep learning curve.
One good thing I've found: if I set the CP on the splash screen, the main window's titlebar displays UTF8 correctly. I assume this means it only has to be done once per session.
Dave... it appears that the new-style cast for
#define HMQ_CURRENT ((HMQ)1)
is
#define HMQ_CURRENT (static_cast<HMQ>(1))
-
I also wonder what's changed given qt5 apparently worked. I'd have to expect something in https://github.com/psmedley/qt6-base-os2/blob/main/src/corelib/text/qlocale_unix.cpp but I don't see anything obviously different.
-
The Qt5 build is currently the same as the Qt6 build when it comes to the titlebar, lots of question marks. It just didn't have the problems with the other weird characters that you fixed.
-
I noticed this in dooble_main.cc,
#ifdef Q_OS_WINDOWS
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL, true);
#endif
Tried adding Q_OS_OS2 to the ifdef, webgl crashed the browser when used. So read up on it, https://doc.qt.io/qt-6/windows-graphics.html (https://doc.qt.io/qt-6/windows-graphics.html).
It is to load a non standard 3D driver including a software solution, they suggest Mesa llvmpipe which would need lvm. There are other software OpenGL drivers around such as TinyGL or PortableGL. Mentore has built TinyGL and I've built PortableGL previously IIRC.
The problem to overcome is that Cloudflare has become the gatekeeper of much of the internet with it's "Are you human" checks. These depend on WebGL to display, so we just get a spinning circle. Even a really slow 3D renderer would be better then nothing for these cases. And actually, given a small window, software OpenGL often doesn't perform too bad.
-
The problem to overcome is that Cloudflare has become the gatekeeper of much of the internet with it's "Are you human" checks.
I think I found an underlying cause for at least some of these Cloudfare checks: the UserAgent string.
A news website I read daily had become unusable because every time I clicked on a link to an article, I got Cloudflare. Casting about for solutions, I reset my UserAgent to the default. Since then, I haven't gotten the Cloudflare page on that site even once (or anywhere else, IIRC). I have to assume that it compares the capabilities that _should_ be present for a given UA with the capabilities the browser itself reports. If they don't match, it assumes something is fishy.
BTW... I'm going to take my titlebar activities to PM/email (at such time as I have something to report or try). Meanwhile, it might be better to put your titlebar tweaks on hold since they'll likely have to be rolled back if my efforts are successful. For the time being, seeing raw UTF8 is unlikely to cause users grievous psychological damage.
-
I'm using the default userstring, today not only am I getting the cloudflare thing, but it is crashing the browser, simply vanishing at first, then when I tried a new profile, crashed recursively, 10 trp files, all sigaborts. Finally tried the Qt5 build and still got stuck in the loop of it checking and failing.
It was on the SeaMonkey newsgroup, alt.comp.software.seamonkey now as Mozilla shut down its newsgroups, that people were blaming the lack of WebGL support for the cloudflare problems.
-
I noticed this in dooble_main.cc,
#ifdef Q_OS_WINDOWS
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL, true);
#endif
Tried adding Q_OS_OS2 to the ifdef, webgl crashed the browser when used. So read up on it, https://doc.qt.io/qt-6/windows-graphics.html (https://doc.qt.io/qt-6/windows-graphics.html).
It is to load a non standard 3D driver including a software solution, they suggest Mesa llvmpipe which would need lvm. There are other software OpenGL drivers around such as TinyGL or PortableGL. Mentore has built TinyGL and I've built PortableGL previously IIRC.
The problem to overcome is that Cloudflare has become the gatekeeper of much of the internet with it's "Are you human" checks. These depend on WebGL to display, so we just get a spinning circle. Even a really slow 3D renderer would be better then nothing for these cases. And actually, given a small window, software OpenGL often doesn't perform too bad.
I had read something similar previously - in theory at least, it should be possible to utilise some of the software GL stuff from Chromium...
-
That was why I enabled it, hoping there was a software GL stuff in there somewhere.
It did produce some interesting trps.
-
Right now, qtbase is configured with '-no-opengl' so it definitely won't work....
-
The Qt5 build is currently the same as the Qt6 build when it comes to the titlebar, lots of question marks. It just didn't have the problems with the other weird characters that you fixed.
Ahh OK :) My bad I thought qt5 worked correctly, I feel better now :)
-
Right now, qtbase is configured with '-no-opengl' so it definitely won't work....
I tried configuring without -no-opengl and with tinygl installed.
configure failed:
Run Build Command(s):C:/USR/BIN/ninja.exe cmTC_d65cf && [1/2] Building CXX object CMakeFiles/cmTC_d65cf.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_d65cf.dir/src.cxx.o
c:/usr/local1420/bin/c++.exe -DHAVE_EGL -std=gnu++17 -o CMakeFiles/cmTC_d65cf.dir/src.cxx.o -c 'U:/dev/qt6-base-os2/build/CMakeFiles/CMakeTmp/src.cxx'
U:/dev/qt6-base-os2/build/CMakeFiles/CMakeTmp/src.cxx:2:10: fatal error: EGL/egl.h: No such file or directory
2 | #include <EGL/egl.h>
| ^~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
Source file was:
#include <EGL/egl.h>
int main(int, char **) {
[[maybe_unused]] EGLint x = 0;
EGLDisplay dpy = 0; EGLContext ctx = 0;
eglDestroyContext(dpy, ctx);
}
Performing C++ SOURCE FILE Test HAVE_GLESv2 failed with the following output:
Change Dir: U:/dev/qt6-base-os2/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/USR/BIN/ninja.exe cmTC_d65fe && [1/2] Building CXX object CMakeFiles/cmTC_d65fe.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_d65fe.dir/src.cxx.o
c:/usr/local1420/bin/c++.exe -DHAVE_GLESv2 -std=gnu++17 -o CMakeFiles/cmTC_d65fe.dir/src.cxx.o -c 'U:/dev/qt6-base-os2/build/CMakeFiles/CMakeTmp/src.cxx'
U:/dev/qt6-base-os2/build/CMakeFiles/CMakeTmp/src.cxx:6:12: fatal error: GLES2/gl2.h: No such file or directory
6 | # include <GLES2/gl2.h>
| ^~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
Source file was:
#ifdef __APPLE__
# include <OpenGLES/ES2/gl.h>
#else
# define GL_GLEXT_PROTOTYPES
# include <GLES2/gl2.h>
#endif
int main(int, char **) {
glUniform1f(1, GLfloat(1.0));
glClear(GL_COLOR_BUFFER_BIT);
}
Need at minimum <GLES2/gl2.h> or <EGL/egl.h> to get thru configure......
-
The Qt5 build is currently the same as the Qt6 build when it comes to the titlebar, lots of question marks. It just didn't have the problems with the other weird characters that you fixed.
I don't see any issue under Dooble QT5, only QT6 has
Here two screencopy of the same link (my web page)
- one with QT5 build, the other with QT6 build.
-
Looks like you haven't installed Paul's latest qos2.dll. You are right that they do display differently though, just not that different.
-
Looks like you haven't installed Paul's latest qos2.dll. You are right that they do display differently though, just not that different.
Right, here after replacing qos2.dll (better but not good)
-
I have a question.
May it be possible the system frozen or hung state, silent dooble close etc... be a result of an audio driver issue ? (uniaudio)
I know, that audio often stop working when playing an audio file and trying to watch a youtube video or when switching youtube videos on the fly with a dooble hung followed by a system frozen state.
I did a high cpu utilization with ffmpeg using 3 different input stream and a very long complex filter with added time delays trying something special, during the run, audio drops working after several seconds... In many cases (like dooble), audio is the first stream not working !
Any idea ?
does dooble have the same issue when different video and audio drivers are used ?
ps: Of course, I tried reducing mem size (having by default the highest possible value)
-
Interesting idea. Guess would need to compare to the USB audio driver. Another possibility is that part of MMOS2 is not SMP safe.
-
Looks like you haven't installed Paul's latest qos2.dll. You are right that they do display differently though, just not that different.
Right, here after replacing qos2.dll (better but not good)
Please roll back qos2.dll and test with https://smedley.id.au/tmp/qt6core-20241203.zip - this has a Proof of Concept fix from Rich.
Cheers,
Paul
-
Looks like you haven't installed Paul's latest qos2.dll. You are right that they do display differently though, just not that different.
Right, here after replacing qos2.dll (better but not good)
Please roll back qos2.dll and test with https://smedley.id.au/tmp/qt6core-20241203.zip - this has a Proof of Concept fix from Rich.
Cheers,
Paul
Yes, title bar is corrected but I saw something else...
The title into the xcenter bar isn't corrected.
-
Yes, the Window List also shows the old broken title. This is due to not using UTF8. I guess the Window list can't be fixed. Rich will have to comment on whether it is worth fixing the xcentre or whether fixing it would have side affects.
-
Yes, the Window List also shows the old broken title. This is due to not using UTF8. I guess the Window list can't be fixed. Rich will have to comment on whether it is worth fixing the xcentre or whether fixing it would have side affects.
QT5 doesn't have this issue...
Is something other missing ?
http://www.altsan.org/os2/toolkits/uls/ulsguide/index.html
-
Interesting. Guess there's another issue, probably codepage related. Try https://ru.ecomstation.ru/ (https://ru.ecomstation.ru/) and you will see the problem with Dooble-Qt5. See what Rich has to say as he is much more knowledgeable on this stuff then I am.
-
Yes, the Window List also shows the old broken title. This is due to not using UTF8. I guess the Window list can't be fixed. Rich will have to comment on whether it is worth fixing the xcentre or whether fixing it would have side affects.
If the final patches I sent you and Paul (in 2 emails) work as expected, this will all be resolved. Western European languages supported by CP850 should look correct everywhere. Russian/Chinese/etc. will display properly in the titlebar but have lots of question marks in the Window List.
-
I have a stupid question !
I found that QT uses a special font including latin etc.... for special characters.
Under \PSFONT I found WARPSANS.FON and WPSU.TTF as well WPSUB.TTF year 2017 (those before 2016 do not have latin.... chars
When I try to change font, the displaied font has by default a different font value then the one under Dooble QT5 (I expected to find the same string)
- Trying to change the font, I only found workplace sans and warpsans isn't into the list (workplace sans should be the same).
- Text rendering under QT5 build is not as defined, dark than under QT6 supposed to use the same font ! (is it using bitmap fonts or ot bitmap ?)
- Which fonts is QT6 using ? The right one including all special language with special chars ? - Does it have an included default font ?
Regards
-
Yes, the Window List also shows the old broken title. This is due to not using UTF8. I guess the Window list can't be fixed. Rich will have to comment on whether it is worth fixing the xcentre or whether fixing it would have side affects.
If the final patches I sent you and Paul (in 2 emails) work as expected, this will all be resolved. Western European languages supported by CP850 should look correct everywhere. Russian/Chinese/etc. will display properly in the titlebar but have lots of question marks in the Window List.
Hi Rich,
I installed the qt6core and have default CP850 code page but as you can see, incorrect chars xcenter list ( the not displayed chars is é )
-
Hi Remy, you are going to have to wait for new builds. I'm currently rebuilding Qt5, Paul will have to rebuild parts of Qt6 and I will have to rebuild both Dooble's. Building Qt is slow.
As for fonts, I assume that only truetype fonts are supported by Qt. Dooble itself seems to reset the window title font on each new start. I haven't noticed any hard coded fonts and likely it is simply asking for a serif or such font and fontconfig takes care of choosing the actual font, though not really sure about it. There are also the fonts under settings.
-
Updated qos2.dll in https://smedley.id.au/TMP/qos2-20241204.zip - needs to be copied over \qt6-6.2.x\plugins\platform\qos2.dll
-
Updated qos2.dll in https://smedley.id.au/qos2-20241204.zip - needs to be copied over \qt6-6.2.x\plugins\platform\qos2.dll
Actually https://smedley.id.au/tmp/qos2-20241204.zip (https://smedley.id.au/tmp/qos2-20241204.zip)
-
Hi Remy, you are going to have to wait for new builds.
Actually, Remy, et al. are going to have to wait for even more new builds beyond those currently available.
Dave/Paul: in my window list patch, I used '.toLatin1()' to generate the switch list text. This is incorrect because Latin1 is not CP850 and produces the wrong accented characters. The screenshot shows QT5 on the left and QT6 on the right. Whatever QT5 does is the correct way to go (but _only_ for the switch list entry - the actual titlebar text must remain '.toLocal8Bit()').
-
https://doc.qt.io/qt-6/qtextcodec.html might help...
QTextCodec *codec = QTextCodec::codecForName("KOI8-R");
QByteArray encodedString = codec->fromUnicode(string);
IBM 850 is in the list of supported codecs.
scratch this, QTextCodec is part of qt5compat which can't be used in building qt6core
-
https://doc.qt.io/qt-6/qtextcodec.html might help...
[...]
scratch this, QTextCodec is part of qt5compat which can't be used in building qt6core
I hate to run people around with a bunch of almost-but-not-quite-right binaries that we could easily test ourselves before release. Could we please take this development process offline until we do get it right? I'll send you and Dave an email.
-
This build, ftp://dry@ftp.os2voice.org/dooble/dooble-2024.12.06-Qt6.zip is the same as the previous build except it has fixed window title for non-English titles, best shown with Remy's page, https://remydodin.levillage.org/en/.Other languages depend on the window title's font having the correct glyphs. Example, https://ru.ecomstation.ru/, which here shows the Russian in the title bar.
Currently Qt6 is missing the code that allows fixing the window list.
Also need https://smedley.id.au/tmp/qos2-20241205.zip (https://smedley.id.au/tmp/qos2-20241205.zip) and https://smedley.id.au/tmp/qt6core-20241206.zip (https://smedley.id.au/tmp/qt6core-20241206.zip)
Thanks to Rich for coming up with the patches and Paul for building the Qt6 DLL's.
-
Also, for both Qt5 and Qt6, the environment variable "QT_PM_CP" can be used to change the code page that the window title uses. To quote Rich,
Paul, setting the CP to 1208 in the environment should also enable
you/someone to test the QT6 sample apps without having to change
a line of code.
Code page 1208 is UTF8.
-
Thanks Dave, Rich and Paul for this fix! Works well here with Dooble using either QT6 or QT5.
Dave, in regards to OpenGL, Paul said QT needs either gl2.h or egl.h to build OpenGL functions. You had made a build of PortableGL whose samples worked well here so I was wondering if PortableGL provided either of those files...
Regards,
-
Also, for both Qt5 and Qt6, the environment variable "QT_PM_CP" can be used to change the code page that the window title uses. To quote Rich,
Paul, setting the CP to 1208 in the environment should also enable
you/someone to test the QT6 sample apps without having to change
a line of code.
Code page 1208 is UTF8.
How do you use this setting ?
I added as environment variable :
'set QT_PM_CP=1208'
This makes Dooble not start
-
Latest Dooble itself does not need the setting, it is for other Qt apps or if you want a different code page with Dooble.
Still it shouldn't crash and doesn't here. Look in popuplog.os2 for a exception report and try running "dooble.exe 2>&1 | tee dooble.log" without the quotes and see if dooble.log has anything interesting in it.
-
Thanks Dave, Rich and Paul for this fix! Works well here with Dooble using either QT6 or QT5.
Dave, in regards to OpenGL, Paul said QT needs either gl2.h or egl.h to build OpenGL functions. You had made a build of PortableGL whose samples worked well here so I was wondering if PortableGL provided either of those files...
Regards,
No, PortableGL nor any other OpenGL library I've looked at have those headers.
-
Latest Dooble itself does not need the setting, it is for other Qt apps or if you want a different code page with Dooble.
Still it shouldn't crash and doesn't here. Look in popuplog.os2 for a exception report and try running "dooble.exe 2>&1 | tee dooble.log" without the quotes and see if dooble.log has anything interesting in it.
I give it a new try and start !
May be I had not enough storage during previous test. System was rebooted since
-
Hi !
I just had a system froze using Dooble qt6.
I don't know if this could help but I had a strange CPU% utilisation !
Regards
-
Ok, I think having found, I left automatic CPU speed increase (Turbo boost) enable under BIOS.
Now disabled.
Seems more stable. One silent close but this time, i've got more informations into stdout logs:
[94:39:1208/234436.722000:ERROR:indexed_db_factory_impl.cc(595)] Failed to GetDBSizeFromEnv: IO error: /000039.log: File not found
-
Profile corruption? If you remember the page that triggered the exception, you could go to \home\.dooble\WebEnginePersistentStorage\IndexDB and move the entry out of the way and see if that helps
-
Profile corruption? If you remember the page that triggered the exception, you could go to \home\.dooble\WebEnginePersistentStorage\IndexDB and move the entry out of the way and see if that helps
I deleted all files and no silent close but about freeze, it is as bad as before I change turbo boost bios option.
When on youtube, trying to open a new tab or moving the page cursor, sound goes into a loop and system freezes...
Reboot required.
The first creating problem is the audio but it seems also been impacted by the mouse movement etc ! driver issue or interrupt priority handling?
-
Latest release, https://github.com/dryeo/dooble/releases/tag/2024.12.31 (https://github.com/dryeo/dooble/releases/tag/2024.12.31) or ftp://dry@ftp.os2voice.org/dooble/dooble-2024.12.31-Qt6.zip.
OS/2 changes, use utf8 in the Window Title as well as show dots for unprintable characters in the Window List. Requires Paul's latest build.
-
Hello Dave.
For some reason I can not open the dooble.exe file with PMDLL.exe
- ftp://dry@ftp.os2voice.org/tmp/dooble-2024-01-09-Qt6.zip
Also, when I run it it says on the About screen that it runs on Qt5.
is that version working fine for you? Or this was a test and I should not use it?
Regards
-
I must have been tired, now fixed including the date. Sorry.
-
Hi!
Since OS2WORD changed its code, I found an issue I think is under FIREFOX and DOOBLE while this doesn't exist under FIREFOX windows
(or a missing code to correctly identify browser width size, environment dependant "CSS" ?)
My screen size is 1920x1200 like under windows.
When under windows, the display changes to adapts the resulting displaied content to the browser width size
- if small, one cols
- if large, all cols (like under previous OS2WORLD code)
Under OS/2, I can change the browser width from very small to its max size (1920) but it always display the site using one col !
This is true under FIREFOX as WELL DOOBLE 5 or 6
-
this is not promising... https://tech.slashdot.org/story/25/03/15/236215/cloudflare-accused-of-blocking-niche-browsers
-
Yes, it has been a problem for a while. Interestingly I notice the list of affected browsers includes otter-browser but not Dooble. Is otter-browser still that well used?
Just updated otter-browser, most commits are about porting to Qt6. CmakeLists.txt still only looks for Qt5
-
The cloudflare thing seems to depend on cookies as well. I can load sites like Slashdot and Sourceforge fine in SeaMonkey, been loading them for years. I had Dooble fail earlier with Slashdot though today it loaded.
This site fails here with SeaMonkey and Dooble, though Dooble got further, https://steamdb.info/ (https://steamdb.info/)
Edit: slashdot fails when I try to login with the cloudflare crap.
-
Since OS2WORD changed its code, I found an issue I think is under FIREFOX and DOOBLE while this doesn't exist under FIREFOX windows
(or a missing code to correctly identify browser width size, environment dependant "CSS" ?)
Sorry Remy, as I explained before, I needed the update the Joomla script on OS2World because I was falling behind with the version and PHP forces to go further or get your server hacked.
The only behaviour that I can explain is:
- Dooble for Windows (narrow) - If the window is narrow it re-accommodate the size layout.
- Dooble for WIndows - if the window is stretch enough it looks as it should. FINE.
- Dooble for OS/2 - Qt5 - No matter how narrow or stretch is the window, the layout looks re-accomodated.
- Otter for Windows - No matter how narrow or stretch is the window, the layout looks re-accomodated.
- Otter for OS/2 - Qt5 - No matter how narrow or stretch is the window, the layout looks re-accomodated.
Just in case I will ask in the Otter forum about why the Windows version is not displaying OS2World fine.
Regards
-
Since OS2WORD changed its code, I found an issue I think is under FIREFOX and DOOBLE while this doesn't exist under FIREFOX windows
(or a missing code to correctly identify browser width size, environment dependant "CSS" ?)
Sorry Remy, as I explained before, I needed the update the Joomla script on OS2World because I was falling behind with the version and PHP forces to go further or get your server hacked.
The only behaviour that I can explain is:
- Dooble for Windows (narrow) - If the window is narrow it re-accommodate the size layout.
- Dooble for WIndows - if the window is stretch enough it looks as it should. FINE.
- Dooble for OS/2 - Qt5 - No matter how narrow or stretch is the window, the layout looks re-accomodated.
- Otter for Windows - No matter how narrow or stretch is the window, the layout looks re-accomodated.
- Otter for OS/2 - Qt5 - No matter how narrow or stretch is the window, the layout looks re-accomodated.
Just in case I will ask in the Otter forum about why the Windows version is not displaying OS2World fine.
Regards
It wouls be interesting to check if the browser width is provided toi the code as it should.
You can create a small web page and display the browser window size
May be you can try :
https://developer.mozilla.org/en-US/docs/Web/API/Window/innerWidth#livesample_fullscreen=demo
It uses javascript.
Of course, css size can be tested too
Update: It seems that some CSS code aren't well handled
Some from: https://www.os2world.com/cms/media/templates/site/cassiopeia/css/template.min.css
You can find into it the @media tag for different browser screen size.
-
I've uploaded ftp://dry@ftp.os2voice.org/tmp/dooble-2025-04-05-Qt6.zip it's sort of experimental, had to revert a change I made to avoid dooble_settings.db being written to the root of the drive that was active when dooble was launched. Something to watch for.
Fixes from upstream include fixing visited links on Qt6. See Help-->Release Notes.
-
Thanks Dave - it's working well here, and I do get the dooble_settings.db in the root of the drive dooble is on..
Regards,
-
It's weird, I haven't had dooble_settings.db written to the root in a week or so. It seems to be the way things are initialized. Upstream changed the startup in main() which created this problem, so I reversed that patch. Now Dooble wouldn't start with this output,
QCoreApplication::arguments: Please instantiate the QApplication object first
QCoreApplication::arguments: Please instantiate the QApplication object first
QCoreApplication::applicationDirPath: Please instantiate the QApplication object first
QCoreApplication::applicationDirPath: Please instantiate the QApplication object first
QCoreApplication::applicationDirPath: Please instantiate the QApplication object first
qt.core.qobject.connect: QObject::connect(QGuiApplication, Unknown): invalid nullptr parameter
Which I fixed by undoing my reversed patch. Need to look more into the startup.
Edit: Same problem with both Qt6 and Qt5
-
There's another issue. Running "dooble 2>&1 | tee dooble.log" I see,
[7699:1:0406/090046.608000:ERROR:system_network_context_manager.cpp(299)] Cannot
use V8 Proxy resolver in single process mode.
[7699:1:0406/090046.634000:ERROR:system_network_context_manager.cpp(299)] Cannot
use V8 Proxy resolver in single process mode.
script_state.h
isolate_ is not broken
script_state2.h
script_state.h
isolate_ is not broken
...
Release of profile requested but WebEnginePage still not deleted. Expect troubles !
script_state.h
isolate_ is not broken
script_state2.h
With the script_state stuff repeated a lot, like a 7MB log after a couple of sites.
Going to multi-process mode does get rid of the 7699:1:0406/090046.608000:ERROR:
Looking at https://github.com/textbrowser/dooble/issues/249 (https://github.com/textbrowser/dooble/issues/249) someone else also has the Release of profile warning, also where he gets,
.org.chromium.Chromium.xxxxx in my ~/.dooble/WebEnginePersistentStorage folder
I get them in %TMP%
-
New release with fixes for the above, ftp://dry@ftp.os2voice.org/tmp/dooble-2025-04-06-Qt6.zip
-
Thanks again Dave! This also works well here - still get the dooble_settings.db in the root. As an experiment, I made a bunch of changes to my settings, closed dooble, then deleted the dooble_settings.db in the root. Opened dooble and all the settings changes I made were still there. So it seems that dooble_settings.db file in the root is totally vestigial and is an extra copy.
Another thing I had forgotten about - it still need the dictionary file to be in the root too...
Regards,
-
Yea, I think the dooble_settings.db in root is a timing issue, created too early and in root then uses the one in %HOME%
Seems the dictionary environment variable has changed to QTWEBENGINE_DICTIONARIES_PATH. Has to be an absolute path and likely needs / as a directory separator. Mine is, QTWEBENGINE_DICTIONARIES_PATH=L:/qt6-6.2.x/bin/qtwebengine_dictionaries
-
Thanks - didn't know about the environment variable. Added it and now don't need the file in root for dictionaries.
I wonder why does Dooble write the settings file at all if it already exists at startup? it clearly reads it from %HOME%, but maybe some part of the code does not get the message it already exists and goes ahead and writes it?
Regards,
-
Seems to zero out the settings path right before creating the application and then figuring out the settings location and creating or loading the settings. I have a hard time following the logic
-
Latest fixes from upstream, mostly NLS related, see release notes. ftp://dry@ftp.os2voice.org/tmp/dooble-2025-04-07-Qt6.zip
-
ftp://dry@ftp.os2voice.org/tmp/dooble-2025-06-01-Qt6.zip
See release notes for latest fixes etc. All changes from upstream.
-
Hello Dave
I get this message, but I have Qt 6.8.1.
------------------------------------------------------------
06-06-2025 09:54:00 SYS2070 PID 01b3 TID 0001 Slot 008e
C:\QT6\APPS\DOOBLE\DOOBLE.EXE
QT6GUI->GCC1.___truncsfhf2
127
Is something that I'm missing?
Regards
-
Looks like Paul used his latest GCC to build qtgui so you need gcc1.dll from that. Attached.
-
Thanks Dave. I don't know why but it is had been hard to all the stuff for me lately.
I'm getting this error. I guess it is because Qt 6.8.1 does not has webengine, right?
------------------------------------------------------------
------------------------------------------------------------
06-06-2025 11:17:58 SYS2070 PID 0045 TID 0001 Slot 001d
C:\QT6\APPS\DOOBLE\DOOBLE.EXE
QT6WEBEN->QMLPLUGN.__ZN8QJSValueC1ERKS_
127
Do you I have to go back to a lower version of Qt6 with webengine?
Regards
-
Thanks Dave. I don't know why but it is had been hard to all the stuff for me lately.
I'm getting this error. I guess it is because Qt 6.8.1 does not has webengine, right?
------------------------------------------------------------
------------------------------------------------------------
06-06-2025 11:17:58 SYS2070 PID 0045 TID 0001 Slot 001d
C:\QT6\APPS\DOOBLE\DOOBLE.EXE
QT6WEBEN->QMLPLUGN.__ZN8QJSValueC1ERKS_
127
Do you I have to go back to a lower version of Qt6 with webengine?
Regards
It looks like it. I also have lost track of Qt6 versions. Dooble's About reports I'm using Qt6 6.2.12 which is what I linked it to. Not sure what the newest version that would work.
-
I was never able to get the 6.2.6 webengine working with QT 6.8. QT 6.6 was the most recent one it worked on. Probably best to just stick to 6.2 for now...
Regards,
-
There was some upstream restructuring of DLL's in 6.8.x....
-
I'm trying dooble-QT6 on a new computer.
SYS0008: There is not enough memory available to process this command.
All available memory is in use. "QT6WEBEN"
This is the output of mem /v
Total physical memory: 15,998 MB
Accessible to system: 1,670 MB
Additional (PAE) memory: 14,328 MB
Resident memory: 148 MB
Available virtual memory: 1,424 MB
Available process memory:
Private low memory: 337 MB
Private high memory: 1,344 MB
Shared low memory: 258 MB
Shared high memory: 1,267 MB
I'm using VIRTUALADDRESSLIMIT=2560
I marked every DLL to load code into high memory -- most were already so marked.
I think for some new machines, dooble-QT6 will be out of reach...
-
I'm using VIRTUALADDRESSLIMIT=2560
I marked every DLL to load code into high memory -- most were already so marked.
I think for some new machines, dooble-QT6 will be out of reach...
Yeah quite possibly. Even with the full 4gb, it's a challenge - with less than this visible to OS/2 - we're pretty much screwed.
-
It's interesting. Here, before loading Dooble-Qt6,
Available process memory:
Private low memory: 306 MB
Private high memory: 2,128 MB
Shared low memory: 223 MB
Shared high memory: 343 MB
After loading it, nothing displayed except about:blank
Available process memory:
Private low memory: 306 MB
Private high memory: 1,956 MB
Shared low memory: 220 MB
Shared high memory: 99 MB
SeaMonkey is using most of my 3.5GB of visible ram and virtualaddresslimit is set to 2944. 3072 causes the system to get unstable.
-
Neil,
I recommend you verify your VIRTUALADDRESSLIMIT setting. Your mem /v output:
Available virtual memory: 1,424 MB
looks to me like I would expect it to appear for VAL 1536.
-
Neil,
Something else must be going on - I am typing this in Dooble on a system that only has 800MB available, using VIRTUALADDRESSLIMIT=2048 and a 2GB swap file. Here's my mem/v while browsing:
[C:\]mem /v
Total physical memory: 32,560 MB
Accessible to system: 824 MB
Additional (PAE) memory: 31,736 MB
Resident memory: 131 MB
Available virtual memory: 2,063 MB
Available process memory:
Private low memory: 324 MB
Private high memory: 1,036 MB
Shared low memory: 238 MB
Shared high memory: 20 MB
Regards,
-
Here are some mem/v results with different VIRTUALADDRESSLIMIT
{0}[c:\] grep VIRTUALADDRESSLIMIT config.sys
VIRTUALADDRESSLIMIT=2560
{0}[c:\] mem /v
Total physical memory: 15,998 MB
Accessible to system: 1,670 MB
Additional (PAE) memory: 14,328 MB
Resident memory: 148 MB
Available virtual memory: 1,440 MB
Available process memory:
Private low memory: 336 MB
Private high memory: 1,792 MB
Shared low memory: 257 MB
Shared high memory: 1,715 MB
grep VIRTUALADDRESSLIMIT config.sys
VIRTUALADDRESSLIMIT=1536
mem /v
Total physical memory: 15,998 MB
Accessible to system: 1,670 MB
Additional (PAE) memory: 14,328 MB
Resident memory: 148 MB
Available virtual memory: 1,440 MB
Available process memory:
Private low memory: 338 MB
Private high memory: 896 MB
Shared low memory: 259 MB
Shared high memory: 819 MB
grep VIRTUALADDRESSLIMIT config.sys
VIRTUALADDRESSLIMIT=3072
mem /v
Total physical memory: 15,998 MB
Accessible to system: 1,670 MB
Additional (PAE) memory: 14,328 MB
Resident memory: 148 MB
Available virtual memory: 1,440 MB
Available process memory:
Private low memory: 337 MB
Private high memory: 2,240 MB
Shared low memory: 259 MB
Shared high memory: 2,163 MB
I'm using the default, SWAPPATH=C:\OS2\SYSTEM 2048 2048
This is a new computer with an i7-14700. With hyper-threading OFF, it has 20 processors.
-
SWAPPATH has nothing to do with available address space.
-
Neil,
I have never seen a mem /v result where the available high process memory is HIGHER than the available virtual memory. Like Steven says, that seems not right. Do you have all settings in your BIOS that reference 'Above 4GB...' turned off?
Also - what motherboard are you using? A testlog file might also be helpful...
Regards,
-
I really don't think the Available virtual memory is accurate as it seems to bounce all over the place. Here with Dooble and SM running, I get close to the same value as Neil.
Total physical memory: 16,270 MB
Accessible to system: 3,502 MB
Additional (PAE) memory: 12,768 MB
Resident memory: 180 MB
Available virtual memory: 1,443 MB
Available process memory:
Private low memory: 306 MB
Private high memory: 1,956 MB
Shared low memory: 220 MB
Shared high memory: 99 MB
I would suggest having a much larger starting value for the swap file to avoid the overhead of growing it, perhaps 1.5 GB and also keep an eye on it. Back in the day I had a system with 1.5GB's of ram, linking xul.dll needed VIRTUALADDRESSLIMIT=3072 or wlink would run out of memory. I had to be careful not to overflow the swap file as the system would die with a swap file full error once the swap file grew to about 2GB. It was on JFS but I assume internally OS/2 uses signed 32 bit variables. I'm sure back in the early 90's it was never expected to use so much memory and/or swap.
-
Neil,
I have never seen a mem /v result where the available high process memory is HIGHER than the available virtual memory. Like Steven says, that seems not right. Do you have all settings in your BIOS that reference 'Above 4GB...' turned off?
Also - what motherboard are you using? A testlog file might also be helpful...
Regards,
Just to be clear that has influence on the total amount of memory. This setting has todo with PCI MMIO regions that are will be remapped when booting ArcaOS in BIOS mode or in UEFI mode. It should not have an effect on the amount of memory you have. Or does it ?
Roderick
-
Roderick,
I mention the 'Above 4GB...' setting because it is something David A. of Arca Noae directed me to change when I had trouble with my new motherboard (B760 chipset, 12th gen i5 CPU) a couple months ago. No idea if it will help Neil directly, but is something to check.
Regards,
-
There are no "Above 4 GB" settings. This is a Lenovo ThinkCentre M90t Gen 5. All my memory posts are just after boot with very little running.
Fortunately the end user probably does not need dooble-QT6. I am successfully running it on some of my older systems.
-
Latest Dooble release, ftp://dry@ftp.os2voice.org/tmp/dooble-2025-07-04-Qt6.zip See help-->Release Notes for changes, all from upstream.