When will we start browsing normally?

Someone explain why Haiku doesn’t have a modern browse? Explain to the average user in simple and understandable speech. Where are unsolvable problems? knowledge? money? lack of time? Or anyone actually tried to run modern browser. In the discussions I found many posts and answers about browsers. But no one final clear. All discussions end whit answers that (for example): we have a WebPositive, Otter Browser, try to QuipZilla or somting else. What is missing to work in Haiku latest Firefox, Chrome or Opera?

Short: developers

Be free to ask Mozilla to port

2 Likes

“Developers, developers, developers!” © Steve Ballmer

2 Likes

We simply do not have the money or enough developers to pay them full time to work on improving our current web browser (WebPositive) or for other browsers, like Chrome or Firefox.

  1. If you want Chrome, Firefox, etc to be running on Haiku. We need more experienced developers who can work with browser technology. It will still take months or years of effort.

  2. If you want it done FASTER, they have to be paid full time. A contract is usually the way it is done here, but without the funds, it is difficult to do this. Therefore you have slow progress or none at all.

2 Likes

And of course it doesn’t matter, but this wasn’t necessary. The reason NetPositive was a decent browser in the '90s is not because the Be engineers that wrote it were so different, but because the requirements for a browser were so vastly less. What all the “progress” since then has bought us, is a lot of glitzy eye candy and browsers that are more complex than the operating systems they run on. I wonder if that has any effect on who’s willing to work on this stuff - the idea of devoting months of work to high tech junk food.

5 Likes

This is such an easy question to answer that I am surprised it was asked.

Setting up a competitive operating system (and browser) against formidable competition isn’t easy and requires a lot of time and skill. We have wonderful and very competent volunteers but there aren’t enough of them. The only solution is to employ people, and that needs money. Next question: how to get it?

Here’s a suggestion. Get 1,000 people to commit to giving $10 per month to Haiku. That will pay for one good or two junior programmers, and the problem will be solved. It’s very easy to set up a continuing payment through Paypal or a variety of other methods, and it is an excellent way for people to help who don’t have technical skills.

Over to you.

2 Likes

To make a browser with support for every things people need and want using it, cant be a work for 1 good programmer and not a really good startup for junior developers.

Some of our haiku devs included so many time into webpositive. You make this hard work bad.

Thanks for all the hard work making a webkit Browser.

Haiku have a smal community. We are not linux or windows. Many people around here give money to haiku over years.

You can try to get this money but to find a developer who have needed skills and api knowledge is not easy. Many of the haiku devs starting very early, then after scool there take Jobs, get family, there is not so much time for them.

So what are your suggestions?

And what do you mean by “you make this hard work bad”?

It all comes down to decisions. As mentioned above in various messages, it’s not possible to get a functioning browser at this rate of code activity. Someone needs to work on it full-time, at least for a certain period of time. To get a full-time developer, one needs money. To get money, there are several alternatives:

  • Market donations more. Ask people to determine a donation amount to download a release (like Elementary OS). Haiku is a unique OS, not like a “slap-everything-together” Linux distribution, and Haiku developers are doing a special job. It needs to be financially appreciated.
  • Set up a Patreon, create some tiers and badges, maybe a flair that’s visible inside the OS, with a unique user ID. Platinum leaf, Gold leaf, Silver leaf, Bronze leaf. For ultra-high tiers, ship some merchandise as a reward.
  • Set up crowdfunding, like Kickstarter, GoFundMe etc.

Unfortunately, web technologies are evolving faster than Haiku can keep up at the current status quo.

There is already a link to make donations in the main page:

https://www.haiku-inc.org/donate/

Yes, It is. Has anyone seen 2019 Haiku inc. financial statement? I was looking for. All i find is a two years old reports and Donations tracking „page 404 error“. Have, for example, someone you knew that Haiku inc. 2018 had more than $24k incomes. During the first quarter of this year Haiku collected more than $3k. Maybe money and salaries for deserving programmers not such a big problem. I agree that not all opportunities are exhausted. It’s basically question about priorities and activities. No one has tried yet crowdfunding, like Kickstarter, GoFundMe or Patreon. It seems to be the community itself will never create modern open source Haiku applications for the needs of each user. We (I mean the average simply user) need to use what is already created the best. Without the most modern and advanced open source applications haiku will be just another big (I mean in size of MB) calculator and “yet another (not) Linux project”. Ok. Well if we don’t have enough resources (money, skills, time, developer’s ant etc.) for to solve such type of problems, we have to look for other alternative and advanced solutions. We have to adapt something else. Something like portable apps, Flatpak, cameyo something like Haiku branch of wine or another way for virtualize and port complicated applications. Maybe I’m wrong. Maybe we (I mean the Haiku users community) are destined to be only interesting and necessary to ourselves.

Been doing this since February of 2010. I’m satisfied with the progress being made.

3 Likes

Thats it.

Haiku team generates a system not end user applications. They do it in there spare free time next Job and family. For the most of them haiku is a hobby and not a payed job they can life for.

If people need special software, they need to start collecting money and searching for extern devs to do this work. The problem is, many new people comes around and shouting around that they need and that must be done.

Start do learn development, start a project, place them on git hub and ask for help, thats the right way. And if some one can get a expierience dev and pay for him, is the second good way.

2 Likes

It’s quite fun because we have built and maintained a complete OS for 20 years, with drivers, user interface, everything, but when it comes to the web browser, the answer is “no, this is not possible and we need full time developers”. I still don’t think that’s true. Qupzilla and Otter browser were ported by a single person who also made the work on the Qt port to get them running. And while I did work full time on WebPositive for a year, I’m not at all happy with the result: my code was not reviewed by other developers, is not as clean as it should, and now I’m tagged as “the WebPositive guy” and no one else is ever touching the sourcecode. This is clearly not what we need.

We need more people to look at the WebKit sourcecode and start investigating and fixing the bugs. A lot of the WebKit code is shared with other projects (including Apple Safari, the web browser in the Sony Playstation, and various open source browsers) and the Haiku-specific parts are in fact not that large. What we need is people investigating and fixing problems there just as they would for other parts of the OS, with a proper continuous integration setup running the tests to identify regressions, a code review process in place, etc. When we have this, not with a single developer, but with a team of maybe 2 or 3, we can even look into upstreaming our work to the main webkit repository.

There are many things to do to improve the WebKit port, on the network side (but we have a GSoC student working on that during the summer), on the graphics side (this will need app_server improvements too), and also in things like moving to the “WebKit2” API to more easily interface with the web browser engine.

As for other browsers, the Chrome team is known to be quite hostile to supporting more OS (they won’t merge even the simplest patches that get things running on OpenBSD, for example). Firefox may be more welcoming, but I think it is not my responsibility as an Haiku developer to take on porting it to Haiku. Start working on it if you can, and maybe you’ll get hired by Mozilla at some point? Who knows :slight_smile:

13 Likes

Actually Net+ was not so great. The lack of a modern browser is plaguing BeOS since the beginning of the Universe. Firefox and Opera gave a great help. But just for a couple of years.

Opera guys are still very open minded on that, but their business model is radically changed in the past ten years so I don’t think they will do it again. They still make money from entities who want to port a browser to their platform (alt-OS guys, ofc). But their revenues come from search referrals, mainly (they also have an ads trading desk AFAIK). And Opera is based on Blink (Chrome)…

Porting Firefox is going to be overkill to me. Firefox is not Otter. I don’t think it could be a one-man band show. And porting Firefox means the need to port a lot of stuff which are not necessarly relevant to a modern browsing experience

Improving as much as possible Web+ is the way to me. Still, I don’t think it could be a one man band show either. Not because PulkoMandy did not do a great job (he did!), but because the application still needs a bit of redesign IMHO.

This is going to be hard, but possible. Unless we will eventually come to the point that to have a modern browser experience, you need an hardware-accelerated browser. This would make things REALLY hard, then.

2 Likes

I agree. Web+ is a Haiku-native app, and it is a great one to showcase. It has the unique Haiku feel within its very design.

So, we need to spike the level of interest in Web+, but how do we do that?

  • Maybe an online Web+ coding sprint, once the Beta2 schedule is over?
  • Blog posts featuring Web+ parts, and how to tinker with them?
  • A bug hunting session before the coding sprint?

you ask for Firefox, Chrome or Opera!?

This is Haiku and Haiku has Web+ (WebPositive), and this browser is native with WebKit running!
Apple is using WebKit and Sony’s Playstation!

I am happy with Web+ and it will be getting better and better with time!

Only money will not! get the developer to work on Web+ only!
Most of them have good jobs and do their work in their freetime on this project!

What do you mean by normal browsing?
Where do you have problems? With which Sites? Where are the problems?
This would help to find answers!

1 Like

Bug hunting is not needed, we have a lot of bugs to analyze in the bugtracker already :smiley:

One thing that would help is getting the web inspector up and running. Currently it’s hard to know what we are doing when working on WebKit bugs.

As for specific parts of Web+, there really isn’t much to say. There are files in platform/graphics/haiku implementing the graphics rendering, they implement the GraphicsContext class from WebKit, using BView. WebKit expects the drawing to run in the main thread, and draw to an offscreen bitmap. The BWebView class takes this bitmap and shows it on screen.

For the network, things are in platform/network/haiku. This code is a mess and needs a large cleanup or probably a rewrite. But as I mentioned, leorize is working on the Haiku side of this (the HTTP code is implemented on Haiku side, there is normally only a thin wrapper in WebKit but it has grown super complicated and broken over the years).

One thing that could be done maybe relatively cheaply in either case is try to use curl and cairo, instead of this custom code. I didn’t want to do that, because it means we don’t get to improve the native APIs. When I was working full time on WebKit and later on with the help of Jua, Stippi, and KapiX, we could spend time improving the app_server drawing performance and fix bugs there. But we didn’t catch everything. That’s also one of the difficulties: few other apps make as much use of the 2D transforms, transparency layers, etc in app_server and WebKit possibly exposes a lot of bugs there, or possibly misuses the APIs but there is no way to know. That is the problem for popupmenus in trac not rendering their borders, for Pootle sometimes not rendering the progress bars for some languages, and many other drawing glitches. There are also parts where we already know that app_server is missing support, for example for the advanced graphics blending mode which are specified in javascript canvas (sourcein, sourceoveer, …) which can’t be done efficiently with the current app_server. In this particular case, WebKit comes with an extensive testsuite and it’s just a matter of looking into each test (which is a simple page with a canvas drawing something and then testing a few critical pixels), comparing with a working browser, and fixing the drawing code to do the right thing.

So, the other option would be to drop the custom BView based drawing code and just use Cairo. But then we would not use the same font rendering as other parts of Haiku, the controls in webpage wouldn’t look exactly the same, etc. And we don’t get to improve app_server. Well, maybe the choice there was too much focused on improving the OS and too ambitious.

In any case, it’s, as usual, nothing magic or crazy complicated. The javascript code could be tricky but that part is almost entirely cross-platform. Event there, one would only touch the most low level stuff like the mmap based memory allocator (for which some changes were already made on Haiku side).

And as a final note, the version of WebKit that ships with Haiku currently is a few years old already. There is a development branch at github with a lot of fixes (both from upstream changes and our own work) but… it doesn’t render our Gerrit page at all (all I see is a white page). If someone fixes just that one bug, we can make a new release with hopefully major improvements accumulated over the years to all other parts. But I wouldn’t want to release it as long as it can’t render Haiku own tools in some usable way, at least.

12 Likes

I’m sure if you recall 3 - 4 years ago, everyone was complaining about Haiku not having “a modern office suite”. Once LibreOffice was available, these requests went away (And will turn into Microsoft® Office® requests).

Now we get people asking for “modern web browser”. WebPositive is Haiku’s equivalent to macOS Safari since it is using WebKit (and migrating to WebKit2), thus is are both “modern web browsers” and both support HTML5. The reason some users keep ignoring WebPositive is because they are most experienced in coming across Firefox and Chrome. So when they ask for those browsers in Haiku our best answer is either WebPositive, QupZilla or Otter which for them it is not good enough. WebPositive is not Firefox or Chrome.

After that, they will question why all these browsers are slow under Haiku. The only answer to this is no graphics hardware acceleration since most websites are now assuming they are running in a browser that has graphics acceleration.

1 Like