Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dmitriy Kuminov

Pages: [1] 2
1
Internet / Re: New Browser Delay Discussion
« on: April 25, 2022, 12:19:31 pm »
Well, that is certainly not ready to be put in the release repo. I can't even read Help-> Documentation, or Help-> Release notes. The pictures seem fine, but the text consists of a line, or blank. I tried on more than one system, with the same results.

This has nothing to do with Dooble or Chromium or Qt. It's the fontconfig (mis)configuration. The Ghostscript libraries (used by CUPS if you have it installed) install some really outdated legacy PostScript fonts like Nimbus which are not Unicode aware. This broken Nimbus is then used as a default (!) font in the system (because of some fontconfig magic). But even if you would get rid of it, you still have outdated non-Unicode Type1 Times New Roman font supplied by OS/2 since ages which gets selected as a default for the "serif" family by fontconfig. And since Chromium/Qt/Google requests "serif" as the standard font for web content by default, Times New Roman gets selected and this makes many pages (including Dooble Documentation) lack any text. Note that if you remove this Times New Roman (TNR.PFB) and friends from /PSFONTS, the mentioned Nimbus will be selected for "serif" with the same effect — lack of Unicode support.

A proper solution is to fine-tune fontconfig for OS/2 so that it ignores Type1 in favour of modern TTF (e.g. ArcaOS comes with the nice Droid family IIRC which works just fine with Dooble). But this isn't an easy task, it needs time to sort things out. As a time being, there are two possible workarounds:

1. Install a well-known font family that has a higher priority in fontconfig (the DejaVu family works great here). This is a preferred solution as it will fix not only Dooble but any Qt/Chromium application.
2. Go to Dooble Settings, Web page, Fonts group, and replace all Nimbus/Times New Roman entries with Droid or any other font that works with Unicode (i.e. not standard OS/2 Type1 fonts).

Perhaps worth mentioning in the Readme.

PS. You can easily check which font Qt will use for a given family request by doing `fc-match FAMILY` on the command line. You may need to run `fc-cache -f` to rescan your fonts after you toss them around.

PPS. Here's the fontconfig ticket, for future reference https://github.com/bitwiseworks/fontconfig-os2/issues/1

2
Internet / Re: New Browser Delay Discussion
« on: April 21, 2022, 01:55:57 pm »
Thanks for your support guys. Yes, I was not right about libvusb and libuvc, it's Lars' work, not Silvan's indeed, sorry Lars.

3
Internet / Re: New Browser Delay Discussion
« on: April 17, 2022, 02:29:23 pm »
Athough it seems that the Qt Company recently (march 2022) released an opensource version of Qt 5.15.3 :

https://lists.qt-project.org/pipermail/development/2022-March/042262.html

(that is more than one year since releasing version 5.15.2, that dmik ported to OS/2)

That's actually a good news which I overlooked being smashed by the crimes of my country. It should be relatively easy to update the OS/2 port of Qt 5.15.2 to it (which will also update Chromium from version 83.* to 87.* with some patches from 88.* according to the readme — with the top version from Google being 103.*). When it will happen exactly - I don't know. Reasons are above.

4
Internet / Re: New Browser Delay Discussion
« on: April 17, 2022, 01:31:34 pm »
Dariusz,

Glad to hear you made it out of Russia and that you're safe...

I cannot overemphasize the importance of this...glad to hear you are OK, things may be a little rough today (believe me, this comes from someone that was a refugee for about 2 yrs. of his life, albeit in a different non-war type of a settings), but with time stability will come as well!

Thank you. Yes, I'm kind of a refugee right now. However, my life situation is still ways better than it is for many Ukrainians. Everyone who can (including me) should definitely show their support to them.

As for the rest, please read my reply to Paul.

5
Internet / Re: New Browser Delay Discussion
« on: April 17, 2022, 01:08:55 pm »
Hey Paul,

Glad to hear you made it  out of Russia and that you're safe.

Thanks.

Quote
I appreciate your post  and update. My comment about 'doesn't smell right' was specifically in relation to Roderick's last update, where he implies that 'others' were behind the switch to Dooble -  you now seems to have confirmed that you/bww chose  to switch to Dooble.  I'm not sure why Roderick was so unclear. Or perhapsI misread and the development is done by bww and the rpm  by  volunteers?

You mix things here. Dooble itself builds out of the box with Qt 5.12 and its Qt WebEngine on OS/2 and so far it has no OS/2 specific patches except adding `-lssp` (because LIBC doesn't do that on it's own when `-fstack-protector` is given). Anyone can easily build it. Elbert Pol discovered Dooble a while ago and we were considering it as a backup while still targeting Otter. Then we just came to a conclusion to release Doodle instead because it performed better. It was a collective decision (OS/2 Voice + bww). Then Gregg Young volunteered to create a Dooble RPM with the help of Elbert Pol while I was not able to work. This is what Roderick meant by 'others' I guess. Then I eventually found time to take it over in order to provide the usual bww quality in terms of release cycles and such.

Please keep in mind that Dooble (as well as Otter) is essentially a frontend to QtWebEngine (Chromium) with little to no platform-specific code. There are some things that may need attention to make them properly work on OS/2 but these are minor (like spell checking, bookmark importing, desktop integration and so on). The core web rendering functionality belongs to QtWebEngine (i.e. the part I/bww was hardly working on through the last years) and has nothing to do with either Dooble or Otter. My guess is that Otter has more stability problems because it makes a more extensive use of various Chromium APIs to implement its rich features like ad blocking while Dooble is much more light weight.

Quote
In relation to "updates having «little to do with the browser»."  I'm clearly not talking about toolchain updates - there have been plenty of non-toolchain updates in recent bww updates (libusb, libuvc as examples  from the most recent bww update).

As I mentioned - these are mostly simple version bumps and they are mostly done by Silvan (who works for bww for free since the last couple of years, I must remind you). I.e. no Qt/browser campaign money is spent there. Although there are some important things like Python 3 also done by Silvan (with some of my help) and these should not come for free because they are needed for Qt/browser/toolchains as well (again, Silvan doesn't charge for that now but this is not right and should be changed).

Quote
The fundamental issue is the lack of transparency.  Why not be clear  where things stand? If you read Roderick's post, the browser has been coming in a few weeks for what seems like years  now.  Your post actually sets out some of the technical limitations blocking progress.

I understand your concern here but providing detailed status reports is also a job that requires human power and time. As we are on a low budget we don't always have enough resources for that. And OS/2 Voice basically volunteers here too. And this was like that before the war, now it's more complicated until settled at least. But we will keep trying to do our best to keep the community informed. Thanks for understanding.

6
Internet / Re: New Browser Delay Discussion
« on: April 17, 2022, 01:09:20 am »
Hey all. I don’t think that using phrases like «doesn’t smell right» is a good way to start a public discussion - I find it provocative and offensive.

Now regarding the matter of the topic (browser delay et al).

I was virtually paralysed when Russia invaded Ukraine and started a war by the end of February. I couldn’t do anything besides thinking on how catastrophic this is for everyone. When I caught my breath I realised that I can’t stand it any longer and need to leave Russia ASAP. It’s not only that it became impossible to do business due to all the sanctions. It’s mostly because I couldn’t tolerate what’s going on. I couldn’t be part of the country that turned into 1930’s Germany (even though I was born there and spent there all my entire life except one year). The least I could do is leave. So I was completely occupied with organising an immediate relocation (with the help of my friends, including some OS/2 folks, as well as some guys from the independent news outlet I also work for).

As I was getting closer to the leave, I got some confidence back and made myself work on the browser a bit between solving numerous move out problems. I don’t understand why this became a subject to criticism as if it were better if hadn’t done this. A few days ago I finally left Russia and plan to stay in Turkey for a while. Currently I’m a person with no home and no residence permit anywhere but Russia (where I’m not going to get back) — and this exposes a huge number of every day problems, starting from inability to have a bank account (and therefore bank cards) to prohibition to stay in a country for more than three months in a row (so I need to move between countries until I get a permit). So until this is solved somehow, my life situation remains volatile and my resources are very limited (in addition to limitations that were already there before the war).

Regarding the overall progress. Our first plan was Otter Browser. We made it to a beta but then decided that it’s not stable enough to be released widely. In parallel, we discovered that there is another Qt-based browser called Dooble. Tests have shown that despite using the very same engine (Chromium) Dooble appears to be more stable than Otter. So we decided to go with Dooble instead. Pretty much simple.

I also want to mention that bww income has dramatically reduced within the last couple of years (mostly because there is not enough parties willing to pay for what we do). I was working full time for bww for many years but last year I realised it can’t go that way anymore because bww just didn’t have enough money to pay me the full salary. I was underpaid for a few months. So I started doing some other stuff in parallel and this of course affected the progress of all our OS/2 projects, including the browsers. Silvan and I were talking about all this more than once. This is the current state of reality.

Regarding updates having «little to do with the browser». This is simply not true. I’m actually surprised Paul is writing such things because he is pretty much capable to understand how things work. Almost everything bww have been doing recently eventually relates to the browser. I’m not talking about small library and tool updates that take little time - I’m talking about updating LIBCn, LIBCx, GCC, Python and a bunch of core tools and libs. All these are needed either for the browser itself or are part of the Qt/Chromium tool chain. In fact, the reason we update them usually is to make Qt/Chromium work.

Also, it’s not true that there is some private source code for the OS/2 versions of Qt/Chromium/Otter/Dooble/whatever. Every single line of code we do is published and every project is buildable from scratch. We (bww) have some private repos but they have nothing to do with the projects we collect money for from the community within the browser campaign. I don’t think that it’s OK to even spread rumours like these without knowing it for sure. It’s certainly a bad attitude.

Another thing worth mentioning is that even Dooble (or simplebrowser) is not 100% stable at the moment. There is a number of known bugs in our port of Chromium that need addressing to make it more stable. There is also a number of technical limitations (like 32 bits) that affect stability and are way more difficult to overcome than fixing bugs. Even if we had a single full time developer assigned to all these tasks, it would not go fast because of the complexity and volume of the code (remember, the original teams working on these projects consist of dozens of skilled developers). But we don’t have even a single one right now. So please don’t expect any outstanding progress in this area. So is the current state of affairs. In my understanding, It’s already a miracle that we got to the point where we are now (having a working Chromium port for OS/2 together with Qt 5).

Porting Qt 6 (as well as fixing Qt/Chromium bugs) is not a problem per se — we have all the tools and all the experience needed for that. What we don’t have (or have not enough) is human resources and money. The best an individual can do here is to either donate what he can, or help with testing and bug reporting, or even help with coding (we accept patches and pull requests since day 1).

I should have more time for OS/2 in the next few days which means that there might be a Dooble RPM for wider testing.

Peace to everyone, I stand for Ukraine.

7
What was the reason why the Otter Browser was chosen in first place? The Qupzilla/Falkon browser is more frequently updated and has a larger user base. It has the same requirement for a current QT framework.
The reason is simple: Falkon (as opposed to its predecessor Qupzilla) is KDE based. So, besides Qt, it also requires a recent version of KDE Framework (KF5) to build. It is a huge project and it is a very complex task to port it it to OS/2.

BTW, Otter is updated not that much but quite frequently, check https://github.com/OtterBrowser/otter-browser/commits/master.

8
Applications / Re: Updated RPMs - big release chunk...
« on: October 12, 2021, 09:42:03 pm »
I am not a programmer so I can't be bothered trying to work out what isn't working, that is the job of those producing the updates before they release them - at least that is how it works in industry.
You are right here. And as any job this one (RPM package tester) should be paid for - at least that is how it works in industry. Currently, there is no such a position at BWW because there is no funding for that. And therefore no person that would do that job. Which leaves us with the only option: ppl do it for free, as time permits, w/o any warranty or responsibility (so no complaints accepted) and anyone who can is welcome to contribute on these terms. This is what Doug is talking about I suppose.

9
Web applications / Re: Otter Browser 1.0 [teaser]
« on: March 08, 2021, 07:02:31 pm »
Thanks everybody!

Dimitry,

great to hear about your efforts! Please make a focus to the installation process. Installation of simplebrowser was not funny and failed on my computer after a lot of trials.

Martin, as already mentioned by Roderick, simplebrowser was never meant to be distributed, it was a build for internal testing only (except that special release from Roderick for a wider audience that was still for testing only and having some RPM/YUM skills was a must). Otter will be distributed as an RPM package so it will install everything it needs automatically provided that you have a working RPM environment (e.g. use the latest ArcaOS). Due to OS/2 specifics, there is simply no other way to properly distribute it (e.g. macOS-like bundle approach will not really work on OS/2 for Otter for many reasons).

10
Web applications / Otter Browser 1.0 [teaser]
« on: March 05, 2021, 07:00:45 pm »
First native OS/2 Otter Browser build ever, enjoy.

There are still some things to polish in Qt and Chromium to make it usable but it's a question of weeks now. One of the things to do is update our current Qt 5.13.1 to Qt 5.15, including Qt WebEngine which will also bring a relatively new Chromium version. Qt WebEngine 5.15 is a requirement in Otter since Nov 2020 (meaning so we are a bit behind until it's done). Updating Chromium is very important as 73.x is a bit outdated (Jan 2019). 83.x is the Chromium version in 5.15.2 and the upcoming 5.15.3 will have Chromium 87.x. This is needed for both performance and stability (Chromium is updated A LOT by Google). Also, there are some Qt issues to fix like system clipboard support which is surely needed for comfortable use.

Stay tuned.


11
Web applications / Re: QT5 simplebrowser
« on: November 13, 2020, 09:31:46 pm »
Hey, just my few cents. Stuff in /test is surely not for general public. So no bug reports etc. are accepted for that. The new highmem fixes some nasty bug in DosRead on JFS which hangs the system if an app tries to load a few hundred megabytes in one go. It's available in the exp repo as RPM now BTW. And you should NOT mark LIBCN0.DLL or LIBCX0.DLL for loading high — it will break virtually everything on your system.

As for the rest, Chromium behaves really faster and smoother here than Firefox in many situations (especially on heavy JS sites) and in general produces lesser CPU load. YouTube playback is slow not because of JS slowness or such, it's because of some incorrect time scale interpretation somewhere on the pipeline, it's just "ticks" 1 ms per 1 s or so. HTML5/JS animations themselves run in the right time scale (e.g. on qt.io). To be sorted out. But again, this is not for general use yet (although it already can do what FF can not since long - e.g. visiting online banking sites etc.). Please stay tuned and consider a donation to BWW if you want to see it ready for general use.

12
Internet / Re: Any updates on the Falcon QT browser?
« on: March 07, 2020, 04:02:13 pm »
Hey Guys,

Otto Browser uses the same web engine as Falkon: Qt WebEngine. It's chromium based and it's what I'm currently hardly working on. Both Falkon and Otto Browser can be built once Qt WebEngine is ready.

Note that Qt WebEngine is not to be mixed with Qt WebKit which was a web engine used in Qt 5.5 and earlier versions (including Qt 4). Qt WebKit is Apple WebKit based and while it can still be built with Qt > 5.5 with almost no effort (we did that for Qt 4 already), it's quite useless. All current Qt based web browsers have switched to Qt WebEngine since long. Qt WebKit is deprecated and it lacks many modern web standards so it's a dead end.

13
Internet / Re: The new browser / QT5
« on: August 19, 2019, 12:32:42 pm »
This really depends on how they decide to go. They made Qt 5 much more modular and plugin based (compared to Qt 4 and earlier) and this is a good thing. It simplifies things a lot (in terms of support and porting to new platforms as well). Therefore I suppose they will leave the overall structure intact this time. Which means less work bringing it to OS/2.

14
Article Discussions / Re: Qt 5 Base for OS/2
« on: August 16, 2019, 02:44:32 pm »
Jochen, I see. This looks like an ANPM bug to me. Please report this situation to their bug tracker at https://mantis.arcanoae.com/. (Apparently they should let the whole update process to complete and only then offer a reboot).

15
Article Discussions / Re: Qt 5 Base for OS/2
« on: August 16, 2019, 12:10:01 pm »
Jochen, how do you install things? `libc-1:0.1.2-1` depends on a newer `klusrmgr-1.2.2-1` which should be automatically dragged in (causing a klusrmgr update before libc) unless you do something special with custom yum/rpm flags.

Pages: [1] 2