One solution I’m trying is to build up Wasmer as a non-browser WebAssembly runtime. This will allow bytecode to rest more directly on the OS itself and native GUI widgets in time. (Presently WASI targets a text-only runtime.) This should drive heavy browser engines into obsolescence.
Litebrowser will build, but you do have to add the full path to various header files. I didn’t know any other way to do it, except create an hpkg that adds the paths, and install them on your system. Doing this would be at your own risk, and I don’t recommend doing anything like this.
As a totally non-technical person, this goes largely over my head. But is Wasmer really capable of largely supplanting existing web-browsers, or is it far in the future?
Because it sounds great, in theory.
It looks like it will trend in that direction. Dart Native and its Flutter framework (from Google) bypasses the document object model (abbreviated DOM) feature of web browsers by using WebGL and WebAssembly. Even within browser frameworks, when performance is desirable, minimal adherance to W3C standards is all that’s needed.
Also, Wasmer isn’t the only runtime for WebAssembly to run outside the browser. It is the most flexible and popular one however. Last I knew they only employed 6 people at Wasmer. There is room for greater achievement. Still, for a small, open-source project, it’s making great strides!
It is nice that you are working on WASM support, but can you please stop bringing it up as the solution to every problem in every topic here? That’s a bit annoying.
Thanks for your rapid reaction to Endorphin! I don’t think it is a dead project: the developer states that he is working on it!
It worked but kept on crashing.
I have now read a few things about browsers and find that most of the work in Haiku should go into Web+ and a non-crashing fast track browser should be available in the meantime. I imagine that a lot of people browse the web before they do any work on Haiku!
I am attempting to code for haiku but cannot access the web for documentation and references.while Web+ collpses in the middle of a page!!
The non-useability of Web+ really is frustrating!
So,I am using Otter and Arora as fallbacks and I shall be waiting for Web+ to become stable…
@PulkoMandy I agree.
This thread was more use to non-developers and for me, I don’t know anything about WASM it sounds like a secret pentagon weapon to me!
Also, in general, when users write about their experiences with Haiku like I was doing with @dasouth initially, developers should not just take over with their jargon and drown information from userland !
“Ignore the user experience at your own peril!” would be my message to developers and coders. There is a place for that in the bug reporting system…
And, by the way, thanks to those developers who have taken Haiku to Beta3! It is a great,refreshing world of computing…
@nipos maybe you should have checked this message by AaronDewes on github before declaring this project as “not really active”?
Sadly, I recently haven’t been focused on this project, but I’ll do some more work soon and make a release. I don’t recommend it as a daily browser though, it’s better if you need something simple as embedded browser<
Maybe you could help people who use Haiku with advice and not discuss coding and software issues in a user forum? I raised the possibility of using an emergency non crashing browser in Haiku and @dasouth did some work to allow me to test a possible new browser in Haiku! That helps the user. Your comments don’t help me at all! Maybe you should work on “… fork QtWebKit itself and keep it updated with the current Apple WebKit codebase …”. To be Helpful means really ‘help’ !
Research compiler / include flags.
I’m sorry I’ve annoyed you.
What annoys me is that we’re still trying to implement the same ideas over and over again. At least this time it’s open-source and standardized.
I have just logged a bug and it was blocked as duplicate… how can I know that my bug has already been reported beforehand? The conditions are different in hardware at website visited for all of my bug reports.
What is the point in reporting bugs if they get killed by others immediately as duplicates??
It only means it was reported already, not that the report was invalid, trac handles this a bit badly since the status becomes “closed”.
Ideally it should be something like “duplicated” and then link back to the first instance of the problem.
Sometimes you can determine with a search when it is already reported, especially if the specific error you get in a debug report (e.g function name) has a report with it already.
This doesn’t always work unfortunately.
@nephele thank you but,…it does not make much sense to report and to read the bug report if I do not really understand what I am looking for? It is like asking Google to search for something and leave the search field blank. Unless I am a Haiku developer I would not know what to search for: the only thing I knew is that it crashed and that I have been asked to add a report, not to read the report and search for a function that caused the bug and which I cannot understand or find in my report or other bug reports!
I do not feel it is useful to report bugs anymore. From me it is ‘silence and wait’ from now on…
@vanitarium this is now completely off-topic with this thread (autocritique)
Would it be possible for the response to indicate the number of the original bug report that is claimed to have been duplicated?
It is noted under the Blocked By field.
The status is closed/duplicate and we add the link to the “blocked by” field. So that’s what we already do.
I think it is simpler for everyone to work this way. Some users have tried to look inside the bugreport by themselves to search for an existing ticket, but they didn’t interpret or understand it correctly, and ended up trying to add info to a ticket that was in fact not related. This ends up being confusing for everyone: developers have to untangle the two different problems in a ticket, and usually will fix only the original one and tell the second person to re-open a separate ticket. It is a lot easier to merge together two tickets that have the same root cause, than to split a ticket containing multiple problems.
That being said, in this specific case it should be pretty easy to see if the bug report points to that same problem or a different one. I have commented on the ticket, explaining how to tell. So you can check that if you want, and report only websites that crash in a different way than this.
You can consider this as our “level 1” support where we do an initial check for the tickets and group together the identical ones, so that the developers can more easily find the info they need. But maybe we can try to give a bit more information to the original reporter when we do this, rather than closing the ticket as duplicate without any further comment, which I see can be a bit confusing. Thanks for reporting that!
No, your bug reports are welcome! I think what @PulkoMandy is saying here, in so many words, is that your bug report was fine, and if you did not know how to distinguish it from other reports, that’s OK, and the developers did that for you; and now you can look at the existing ticket to see the progress (or lack thereof) being made towards a fix.
Thanks @waddlesplash it is finished now. I was insulted by a member of the forum who does not understand my position. So I am a bit upset. I expect a wee dram will cure it🥃
Misunderstandings can occur when everybody is using their native language. When, as here, many people are not native English speakers, the chances of misunderstandings are greatly increased.
So have your dram, and if the first one doesn’t work, then keep trying. And in the morning, please come back and report some more bugs.