[haiku-development] Re: Firefox port [was: Re: R1/a4 initial planning]
- From: Alex Wilson <yourpalal2@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 18:05:58 -0700
2012/2/23 lodewijk andré de la porte <lodewijkadlp@xxxxxxxxx>:
>> >> I'd love to see WebPositive development continue as fast as possible.
>> >> So
>> >> certainly, anyone wishing to work on WebPositive should do that rather
>> >> than
>> >> invest time in a Firefox port. But, in the hope that Haiku is again
>> >> chosen
>> >> as
>> >> a mentoring organization, we need project ideas and I find the Firefox
>> >> port a
>> >> rather good one.
>> >
>> >
>> > +1
>> >
>> > Bye,
>> > Axel.
>> >
>> +1
>> And make sure Web+ can block all content from sites the user adds to
>> the blacklist, including javascript, popups and images especially from
>> doubleclick.net adsnx.com and <anynumber>.com
>
>
> I think the idea of a native browser is a very good one. It'd like to list
> some things I like to see in a browser:
>
> - Extendability, nothing is ever finished and you can't do the work on your
> own
> - Reliability, it's not that bad if something fails every so often. As long
> as it works most of the time and fails with grace.
> - Speed, I'm a programmer. I know things can be fast. Rule of fist is "if it
> takes a long time, it's done wrong", for most programs that means that if I
> see it happen, it's too slow.
That absolutely doesn't work in a web browser. Programming can only do
so much in the face of network latency!
> - Compatability, I was a sucker for ACID3. It was the primary reason I
> switched to Chrome. Chrome is also fast and gracefully fails. I like it
> quite well.
> - Minimal, out-of-my-way. We're here for the web, not the browser.
>
> Given webpositive will use webkit for at least a reasonable time. Likely V8
> for JS. It´ll have fast rendering and JS. It´ll also be compatable. If
> blitting´n all are a problem Haiku should be fixed until it´s not. Fast
> rendering and blitting are important.
> To minimize the chrome and get some haiku-specific competitive edge I think
> it'd be nice to have every tab have a window to use the pane-stacking as tab
> management. It'll effectively eliminate the tab bar from the chrome and
> really make some use of that stack-and-tile functionality in the window
> manager.
>
> All other functions could be made accessible through a right-mouse menu and
> keyboard shortcuts. It should be attempted to provide a minimal amount of
> function to still cover all needs.
Why would you completely delete the entire interface? Navigating is a
core function of a browser, and shouldn't be relegated to right-click
menus.
> Last but not least, a plugin system that allows to place extra
> context-sensitive info in the right mouse button. To inject JS into pages.
> To place a button to the left or right of the address bar (drop-down
> optionally?). To access the DOM on pages on which they become enabled and
> open their own pages (access the DOM accross those). Those things combined
> should make the majority of tasks possible. There could be a pre-parse html
> function, for filtering ads and tracking before they have a chance to show.
> There must be a little plugin-store too.
>
> Honestly, if this could be made I'd be able to spend 90% of my time in Haiku
> OS without compatibility problems.
You've basically just described Chrome, but with less GUI 'chrome'.
Chrome is huge, it's a big project with full-time developers. If you
want Chrome, the best bet is to port it, not rewrite it for Haiku.
Maybe we could add an option to Chromium to use Haiku's S&T
functionality for tabs, but there's really no sense in dedicating all
of our resources to duplicating Chrome (it would probably take more
than all of our resources, actually).
--Alex
Other related posts:
