Dooble releases-Qt6

[Dave Yeo]

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.

[Mike Kölling]

Hi Dave,

Thanks again for your nice work. I my case I would like to have the German language available.

Greetings, Mike

[Bernhard Pöttinger]

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

[Rene Hvidsoe]

Seems to run nicely, just testet very little with few sites.

Best regards

Rene

[Dave Yeo]

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.

[David McKenna]

 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,

[Paul Smedley]

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.

[Dave Yeo]

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

[Dave Yeo]

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

[Paul Smedley]

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....

[Paul Smedley]

<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?

[Andrew Stephenson]

<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.

[Lars]

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 ...

[David McKenna]

 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,

[Paul Smedley]

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...