Native 68k Netsurf

[wawrzon]

please guys, bernd is not trolling even if it looks like that. given his record of engagement for 68k, even if he is an uae-guy, he just tries to be reasonable about what can be done given current ressources. lets be honest, it doesnt look like we have any magick coders around any more.
i personally am all for trying to get netsurf with a native frontend and see if this helps, but im a noob who isnt even able to do it even if i would like. artur at least did a sdl port with bernds and itix help, which is an achivement we should be grateful of. and bernd considers netsurf easier to maintain without too much amiga-code in it. thats his point. thats it.

and now back to topic, did anyone got any further with it in the meantime? i pass for the time being, sorry.

[unusedunused]

if c2p only costs 10% then it would advocate to include support for it it into sdl or netsurf.

it cost sure much more time, but i use optimistic 10% value and i reach 2 minute market to show this page.every 10% slower give at 120 sec 10 sec more

>With attitudes like yours we would not have doom, scumm, mp3 >playback etc on the classic Amiga.

doom scumm mp3 play is usable with afats classic user.

but now tell me which user  play doom on his AGA machine ??
does mp3 play in realtime on the 68030 ?

>Netsurf is only possibility to get modern browser for 68k amigas, it >will require some work. There will be new network stack for our >amigas and it would nice if we could get native Netsurf same time.

yes its nice, i told when i need not program it, i use it too.

But i dont want invest lots time for it, i think i need more than 600 hours for this.and later need more to keep update.

maybe a user that want netsurf on a AGA amiga can answer the questen.

If you can program and you can do a native GUI for netsurf in 600 Hours, do you really want spend this lots of work to see netsurf run on your AGA amiga without Java script and frames ?

reason for me its not worth the big work now, and keep it upto date during netsurf enhance.

so the longer you wait, the less work you have.and to see how netsurf grow and fit your needs and pages SDL version is good, you can not reach faster speed.

but things change maybe when netsurf get usefull speedups, frames and java script.

but before maybe OWB work on AOS.

Here is a mail, what problem it is to make a native GUI.
the atari mint version is develop many months now.

http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-March/002417.html

[chris]

As iv'e said If we get it running, it's a start. Alterations to the code base can happen from there. More coders will be willing tomuck in once they see something running, the Same as happened with AROS, and I don't care if we start to wander away from the main fork either.

Exactly.  I agree with everything you wrote (not just the quoted bit).  Getting it running is the first step - Bernd & Artur's work proves that the core works on OS3/68k, next step is to get a native frontend.  We can optimise after that.  Bernd says the main bulk of processing is parsing and layout - well, that's due to be improved for NetSurf 3/4 anyway.

and now back to topic, did anyone got any further with it in the meantime? i pass for the time being, sorry.

You might like to try compiling the "monkey" frontend.  That will prove your build system is set up correctly.

Here is a mail, what problem it is to make a native GUI.
the atari mint version is develop many months now.

http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-March/002417.html

That's mostly irrelevant, since we have a frontend that just needs back-porting.  Also the Atari port got results quite quickly, adding on the extra months used to develop it further is missing the point somewhat.

[wawrzon]

dont see any monkey frontend here  to compile for..
i think the build system is set up ok. just to reprogram the amiga frontend is a little too much one could expect from me..

[unusedunused]

>That's mostly irrelevant, since we have a frontend that just needs >back-porting. Also the Atari port got results quite quickly, adding >on the extra months used to develop it further is missing the point >somewhat.

thats same, i tell this in ML, the problem for me is not to write a GUI and Code to read or set the values, this i can do in 1 Hour with stormwizard

http://stormwizard.amiforce.de/

I can  write faster a stormwizard GUI than porting your reaction GUI, the problem come when something not work, there need understand how netsurf core work.and to learn how netsurf work cost much time i think, and more because no good docu is here

You or netsurf team do not compile or test 68k Port, so if something is change in main core, then need search wy it not work.

I look now into new libnsfb, now is a function in bitmap scale.
This let show in amiga.org the bars correct.

but with needed scale feature, netsurf get slower i think.and more slower of course on AGA

[utri007]

More coders will be willing tomuck in once they see something running, the Same as happened with AROS, and I don't care if we start to wander away from the main fork either.

This is how it usually happend No matter how crappy first actually running port is, it makes native netsurf more interesting to others, wich include other coders.

Eventually that makes everything easier and development is accelerating as more people are involved it.

So don't hesitate to make first possible version public, mean v. 0,01b

[eb15]

If you don't like the idea of working on yet another Amiga port of netsurf, there's always other fish in the sea.  Maybe you would be more interested in porting Amaya (the w3.org HTML, CSS, and SVG editor and browser program) to your choice of interface.

[wawrzon]

have you seen what dependencies that demands? wxwidgets port would be a major task i suppose. why to propose such a complicated thing if even mauch simpler doesnt get done?

[chris]

dont see any monkey frontend here  to compile for..
i think the build system is set up ok. just to reprogram the amiga frontend is a little too much one could expect fromme..

The monkey is new, you'l need to update to latest SVN.  It's better to do "svn co" and "svn up"  instead of downloading the tarballs.

 

I can  write faster a stormwizard GUI than porting your reaction GUI, the problem come when something not work, there need understand how netsurf core work.

I've been working on it a couple of years, and only have the vaguest clue how the core works.  You don't need to know.  Any API that the frontends used is either obvious, documented or can be nicked out of one of the other frontends.

You or netsurf team do not compile or test 68k Port, so if something is change in main core, then need search wy it not work.

It's quite rare for core changes to need frontend changes, and if they do then usually the person making the changes fixes up the frontends as best as they can.  I've been through this already.

Anyway, this is one of the reasons why I suggested backporting the OS4 frontend instead of creating a new one.  Anything like that I'm going to be fixing anyway, all it needs is compiling and testing on OS3.

but with needed scale feature, netsurf get slower i think.and more slower of course on AGA

It's as slow as BitMapScale(), which is the same speed whatever the graphics output device.  Scaling before or after converting to 8-bit might make a difference.  This is all optimisation that can be investigated after we have something working.

[unusedunused]

The monkey is new, you'l need to update to latest SVN.  It's better to do "svn co" and "svn up"  instead of downloading the tarballs.

I dont understand what monkey frontend is.Have you a link or so ?
SDL is only choose because GTK is too big, slow and memory hungry

If there is another netsurf frontend that is keep maintained its maybe interesting to compile this for AOS 3

>I've been working on it a couple of years, and only have the vaguest clue how the core >works. You don't need to know. Any API that the frontends used is either obvious, >documented or can be nicked out of one of the other frontends.

for me its important to understand how all work, when i program more and the compile and run fail.

But for Port i dont need know how it work

[chris]

I dont understand what monkey frontend is.Have you a link or so ?

It's a dummy frontend.

[utri007]

Netsurf version 2.7

* Some incomplete work towards AmigaOS 3 support.

What this actually means? How this makes easier to port it to 68k?

[x303]

If you don't like the idea of working on yet another Amiga port of netsurf, there's always other fish in the sea.  Maybe you would be more interested in porting Amaya (the w3.org HTML, CSS, and SVG editor and browser program) to your choice of interface.

Looks this isn't going to be updated anymore, although the mailinglist is still full of bugreports. Better choose an active one, like netsurf...

[x303]

If you don't like the idea of working on yet another Amiga port of netsurf, there's always other fish in the sea.  Maybe you would be more interested in porting Amaya (the w3.org HTML, CSS, and SVG editor and browser program) to your choice of interface.

Looks this isn't going to be updated anymore, although the mailinglist is still full of bugreports. Better choose an active one, like netsurf...

Anyway, this is one of the reasons why I suggested backporting the OS4 frontend instead of creating a new one.  Anything like that I'm going to be fixing anyway, all it needs is compiling and testing on OS3.

Right On

[utri007]

Netsurf is easiest and only realistic choise port to 68k. Luckily spammers hasn't start to pollute this thread with OWB/FireFox/Amay etc posts.

[eb15]

My earlier response was due to someone legitimately stating they thought creating yet another GUI for a standard web browser engine would be to themselves a boring job.  (keeping netsurf or owb internals as a closed box unto itself)

I was expecting someone to say Amaya was outdated (and it is).  However Amaya does CSS and SVG web content creation (which could possibly be extended and updated), and had hooks to connect to a javascript interpreter, which could make it a more interesting project to a developer than just trying to hack a basic GUI wrapper program onto another generic browser engine.   Creating custom Amiga gadgetry objects that can do what the wxWidgets functions did could do be an interesting challenge and might help facilitate other wxWidget based software ports.    

Eventually OWB for AROS will be compiled for the m68k-aros platform so  someone will see how good or bad that works out to be in relation to  netsurf-m68k.  If both of those are too resource heavy, it may be possible for someone to revitalize the old AWeb sources, and graft CSS into it for an alternative.  

An other interesting idea would be to rip apart the various open source web engines, game development systems, and media content players (along with consulting available docs for the latest versions of things like HTML5, flash and pdf to gather information about their object and method support needs) and use the info to design and create a whole new GUI toolkit (and content creation apps) for the Amiga-like OSes that would support cross development between web app space and a more private platform (Amiga) app space..