Re: Atari front end
Hello Michael, Am Donnerstag, den 10.03.2016, 19:34 + schrieb Michael Drake: > Are there any Atari users around? > > Could you let us know if the current m5475 and m68k builds are working? > > http://ci.netsurf-browser.org/builds/atari/?C=M;O=D I tried the m68k version. Rendering and JS seems to work fine. GUI actions work fine, all the windows (history, cookies, bookmarks, browser) show up and do their job. Except verbose-log, selecting the menu entry "verbose log" without having started netsurf from the console, causes a crash. I did NOT test network access. Browsing local files works fine. Greets, Ole
Re: Javascript features list
Am Freitag, den 19.02.2016, 20:11 + schrieb Peter Slegg: > I am looking at a survey form and wondered if buttons should work ? When I testet JS builds for Atari three weeks ago, onclick for buttons worked well. What does the verbose log say? And what do you expect? The code inside the onclick attribute seems to disable the button when validation fails. But I guess the rendering engine does not deal with such dynamic changes right now. Maybe there is also an exception... the log will tell you more. Greets, Ole
Re: Very slow page rendering
Am Donnerstag, den 28.01.2016, 21:04 + schrieb Peter Slegg: > > https://www.royalmail.com/track-your-item > > Another page that took ages to display and looked like the css had > failed as well. > Early versions of the atari port crashed because of stack size issues (caused within mintlib regex module, called by NetSurf CSS parser, while it was processing exorbitant strings (3k, which expanded to several MegaBytes within mintlib regex module)...). I prevented the crash by compiling mintlib with the +DEFS=-DREGEX_MALLOC define. This is also applied to the CI builds. Just a guess: there is some kind of slowdown when doing excessive malloc operations with MiNT. Greets, Ole
Re: JavaScript enabled builds for Atari
Hello,
enabling JS for the atari builds was great :-)
Attached is a screenshot of another testpage from the NetSurf JS
Testsuite.
Things like works fine.
document.getElementById() works, also document.write() works, at least
when called during the rendering phase.
The JS Prime-Test page took 160 sec. to load here, which is expected by
me.
document.getElementById('xyz').innerHTML = "New Content";
- does nothing.
document.getElementById('textarea').value = "New Content";
- does set the correct value, but the GUI is not refreshed. If that
would work, NetSurf would be able to provide some kind of JS-Calculator,
using the textarea as the display...
I can confirm that the ASCII-fractal is rendering fine, took 8.6 sec
with m68k-aranym (Clocking: 300Mhz).
Very promising, looking forward for some possibility to redraw the
page/HTML Elements :-)
Greets,
Ole
Am Montag, den 25.01.2016, 21:12 + schrieb Peter Slegg:
> >Date: Sun, 24 Jan 2016 09:53:46 +
> >From: Michael Drake
> >Subject: Re: JavaScript enabled builds for Atari
> >To: netsurf-users@netsurf-browser.org
> >
> >
> >
> >On 23/01/16 23:06, Peter Slegg wrote:
> >
> >> Using Netsurf JS today it has crashed a few times.
> >> It isn't as stable as the last non-JS versions.
> >
> >How about when you use it with "enable_javascript:0"?
> >
> >Michael Drake http://www.netsurf-browser.org/
>
> With JS disabled it seems to be as stable as normal, no crashes
> since disabling JS yesterday and using JS to visit 20-30 pages.
>
> Is there a JS test page that can be used to check simple JS features ?
>
> Regards,
>
> Peter
>
>
>
>
>
>
Re: Jenkins webpage
Am Sonntag, den 18.10.2015, 18:17 + schrieb Peter Slegg: > Hi Ole, > > Screenshot attached showing, what I think, are the build servers > above the CI modules. > Hello Peter, firefox also renders it that way. So that doesn't look like an error in the atari frontend. Greets, Ole
Re: Jenkins webpage
Hello Peter, Am Sonntag, den 18.10.2015, 13:30 + schrieb Peter Slegg: > I was just having a look around the Netsurf devs area and noticed > that the Jenkins page is not displayed correctly. > > http://ci.netsurf-browser.org/jenkins/ > > The menu that should be on the left is being shown at the top. > > Atari build 2999. Can you please provide an Screenshot? Greets, Ole
Re: Running netsurf 3.3 on Raspberry Pi in framebuffer
Hello Karel, > (0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804 > (0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl > surface is not available from libnsfb > > Am I missing something or do I get the error because of the 3.4 (Dev) > version ? Can someone please give me a hint how to fix this ? Did you already to try to run the framebuffer version under X11? the libnsfb can be compiled with several backends... SDL is one of them. When the build system does not detect SDL correctly (and you do not configure it manually somehow...), it probably just skips the build of the SDL backend. Maybe you have luck and the X11 backend was put into your build of libnsfb. Otherwise, make sure that libnsfb is compiled with SDL backend. I once had an problem with that...: libnsfb make use of some gcc feature (a ctor function for libraries..., something like that) which was unsupported by the GCC cross compiler that I used: SDL was never registered as valid backend when libnsfb was loaded and always reported that the SDL backend is not available... I had to manually call the registration of the backend at application startup time. But I think this was a very rare problem, I guess the buildsystem did not find your installation of SDL development files. Greets, Ole
Re: Cache on Atari build
Hello. >Am Donnerstag, den 02.10.2014, 09:10 +0200 schrieb J. F. Lemaire: > On 2 October 2014 00:38, cj wrote: > > I would have thought that any sensibly implemented system should > > automatically create folders that do not exist, rather than die. > > That's what happened on my Atari system so I'm surprised that it > wasn't the case for Peter. Unpacking the package makes sure there is an folder called res/cache, AFAIK. I don't know how the netsurf core behaves when the folder is not found. Greets, Ole
Re: CSS Base
Hello, thanks for keeping an eye on the dev builds. The latest build (2106) should be fixed. For more information see the commit: http://git.netsurf-browser.org/netsurf.git/commit/?id=d7f479070e6a198084f92e77c26b9bb0e8cab471 Greets, Ole Am Freitag, den 12.09.2014, 19:39 + schrieb Peter Slegg: > I just tried the latest daily Atari build (2105) but I am still getting the > CSS Base error message. > > At that point the log file looks like this : > > > (5.875000) content/content.c content_convert 283: content > file:///./hotlist.htm (0x1b1be0c) > (5.875002) render/html_css.c html_css_quirks_stylesheets 503: 4 fetches active > (5.875003) render/html.c html_convert 1028: quirks set to 2 > (5.875004) render/html.c html_convert 1032: 3 fetches active > (5.88) atari/gui.c gui_poll 144: WM: 4944 > > (5.955002) render/html_css.c html_convert_css_callback 112: stylesheet > file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed: > UnacceptableType > (5.955003) render/html_css.c html_convert_css_callback 116: 2 fetches active > (5.975000) render/html_css.c html_convert_css_callback 112: stylesheet > file:///user.css failed: UnacceptableType > (5.975001) render/html_css.c html_convert_css_callback 116: 1 fetches active > (5.99) render/html_css.c html_convert_css_callback 112: stylesheet > file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cquirks.css failed: > UnacceptableType > (5.990001) render/html_css.c html_convert_css_callback 116: 0 fetches active > (5.990002) render/html.c html_begin_conversion 1085: Completing parse > > > I don't know what to try that might help. > The last working version I have is No. 1917 > > Peter > > > > > >
Re: CSS Base
I can see the following message in the log: (13.530001) render/html_css.c html_convert_css_callback 112: stylesheet file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed: UnacceptableType Also, I hope that the URL appearance is OK at that point, the URL Encoding must be removed when it is used as file path. I did not follow the URL handling changes and maybe this doesn't work correctly at the atari version. Greets, Ole
Re: CSS Base
Looks like it's failing to find its resources. Neither the default style sheet or the Messages file have loaded. I don't know how the Atari front end deals with loading them. Nope. These files are loaded correctly, I had a look at the debug log. I suspect the Messages file isn't up to date. Peter, did you also update the Messages file? When you updated the Messages file, and still get the CSSBase error, the archived Messages file inside the atari autobuild is erroneous. However, CSSBase stands for the well known error "Base stylesheet failed to load". I can see the following message in the log: (13.530001) render/html_css.c html_convert_css_callback 112: stylesheet file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed: UnacceptableType (13.530002) render/html_css.c html_convert_css_callback 116: 2 fetches active (13.55) render/html_css.c html_convert_css_callback 112: stylesheet file:///user.css failed: UnacceptableType (13.550001) render/html_css.c html_convert_css_callback 116: 1 fetches active (13.565000) render/html_css.c html_convert_css_callback 112: stylesheet file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cquirks.css failed: UnacceptableType (13.565001) render/html_css.c html_convert_css_callback 116: 0 fetches active (13.57) render/html.c html_begin_conversion 1085: Completing parse To me that looks like some function stopped to return correct filetype now fails for some reason, maybe here: http://git.netsurf-browser.org/netsurf.git/tree/atari/filetype.c#n34 But I'm not sure, maybe the netsurf dev team knows about changes in that region. Greets, Ole
Re: CSS Base
> Does anyone know what is wrong with the Atari daily builds? Any page just opens a dialogue box saying CSS Base (attached). No pages are rendered. Can you please send the log? I'm not at home because I broke my leg, but maybe there is something interesting to see within the log. Please also try to run netsurf from U:\ and via toswin2 shell, etc... You and I know the desktops behave differently when it comes to the current working directory... maybe it's still not handled absolutly correct. Please, also provide which desktop / AES you are using. Greets and Thanks for reporting.
Re: Netsurf on arm linux sdl framebuffer.
Am Donnerstag, den 24.04.2014, 17:23 +0200 schrieb samuel zimmer I was using the internal font. Now I am trying with freetype but I am getting these errors: LINK: nsfb /usr/lib/x86_64-linux-gnu/libm.so: file not recognized: File format not recognized I am trying to get it to look in my cross compile root and not try to use my main system libs. So far no go. Just to be sure, you have read: http://wiki.netsurf-browser.org/Documentation/GettingCoding right?
Re: Netsurf on arm linux sdl framebuffer.
Am Donnerstag, den 24.04.2014, 17:23 +0200 schrieb samuel zimmer : which version of netsurf. I am using freetype 6.3.8 with netsurf 3.0 The freetype version is not correct. Maybe that's an package version? I was using the internal font. Now I am trying with freetype but I am getting these errors: LINK: nsfb /usr/lib/x86_64-linux-gnu/libm.so: file not recognized: File format not recognized I am trying to get it to look in my cross compile root and not try to use my main system libs. So far no go. You can probably adjust the path directly in this file: http://git.netsurf-browser.org/netsurf.git/tree/framebuffer/Makefile.target ...but also have an look at Makefile.config in the root of your netsurf source tree! Your build environment is broken when it uses the wrong pkg-config installation (directory). In the end, that means netsurf-buildsystem will not use the correct libs. You may want to use hardcoded lib path in the Makefile.target file, as long as you don't want to fix your build env. You can also enable verbose compiling at: http://git.netsurf-browser.org/netsurf.git/tree/Makefile#n134 http://git.netsurf-browser.org/netsurf.git/tree/Makefile#n135 (comment the lines). Then you can copy the erroneous linker statement, try to fix it, paste it to the console again, and execute again. Maybe freetype uses a special pkg-config script called "freetype2-config" or such... (same may applies to other packages...).
Re: Netsurf on arm linux sdl framebuffer.
Am Donnerstag, den 24.04.2014, 15:55 +0200 schrieb samuel zimmer : Seem like my first message got all garble up. Trying plain text. Hello! Some stats about my toolchain gcc 3.3.4 glibc 2.3.2 binutils 2.14.90.0.5 curl-7.35.0 libpng 1.2.51 libxml2 2.9.1 openssl 1.0.0l SDL 1.2.15 libmng 1.0.10 jpeg 9.0 zlib 1.2.8 You missed to mention which version of freetype you are using and which version of netsurf. First I got this error cc1: error: unrecognized option `-Wextra' I removed `-Wextra' from libnsfb makefile libosprite makefile Then I got this error cc1: error: unrecognized option `-Wstrict-aliasing=2' I removed `-Wstrict-aliasing=2' from libosprite makefile Then I got this error cc1: error: unrecognized option `Wno-overlength-strings' I removed `Wno-overlength-strings' from libnsfb makefile Then I get this error src/surface/sdl.c:11:21: warning: SDL/SDL.h: No such file or directory The file is there by all the other headers eg. "/home/fred/netsurf-full-3.0-tt/prefix-framebuffer/include/SDL/SDL.h" if I hardcode the path from #include to #include "/home/fred/netsurf-full-3.0-tt/prefix-framebuffer/include/SDL/SDL.h" it compiles fine. I can only guess that either your compiler is to old or your build environment isn't setup correctly. Maybe some syntax error at the commandline, or maybe a wrong path... When it runs it no text displays. If I point it to a image (file:///home/fred/image.png) it displays fine but does not render html. Did you try with the internal font? Or did you try freetype? You probably should look at that, anyway. Greets, Ole
Re: Yahoo groups
Am Sonntag, den 02.03.2014, 11:43 +0100 schrieb Peter Slegg : I have accessed Yahoo groups before but when I tried just to open various pages I keep getting the error: Unable to fetch document I am using version Atari 1741 Did you: - enable verbose log - enable curl debug output (not sure if there is still an option for it) - does it also happen with a previous release? Maybe yahoo changed something ;) Greets
Re: Atari daily build
Am Samstag, den 11.01.2014, 17:04 +0100 schrieb Peter Slegg : Unfortunately I could only find 1555 on the daily build page and that has the error also. So it appearred between 1541 and 1555 inclusive. Thanks for investigating this, I will see which changes were done during these Builds. Greets, Ole
Re: Atari daily build
Am Donnerstag, den 09.01.2014, 22:19 +0100 schrieb Peter Slegg : The Atari daily build is still broken. It renders the url underscores but not the fonts and then exits abruptly. I will have a look at this, but not very soon. If you can make out which build introduced the bad behaviour, that would be top. Otherwise I will investigate by debugging, analyzing the build and some changetrial and error changes to the Makefiles. Greets, Ole
Re: Fanfiction.net login
Am Donnerstag, den 28.11.2013, 00:12 +0100 schrieb Harriet Bazley : It's definitely some kind of CSS problem and not JavaScript, because doing a 'full save' and deleting the CSS files causes the image to appear. Maybe that's what the CSS designer wanted: Have the element initially invisible. It can be set to visible via JavaScript in most browsers ;). Greets, Ole
Re: Fwd: Re: Netsurf/atari build 1501
Am Mittwoch, den 27.11.2013, 21:54 +0100 schrieb John-Mark Bell : Evidence, please. With libdom, this should be significantly faster, as string comparisons no longer need consider the actual string data. That was mentioned at the IRC channel several times, someone also made a calltrace with timings and people started to talk about the CSS class matching. As far as I had understood, libdom is still subject to some optimization to have the same perfomance as the previous implementation. But It looks like I completely misunderstood it? Greets, Ole
Fwd: Re: Netsurf/atari build 1501
Am Mittwoch, den 27.11.2013, 20:35 +0100 schrieb Peter Slegg : I installed the Atari build 1501 and subjectively it seems slower, mostly after the page has been rendered, Netsurf pauses for over a minute before the page can be scrolled or anything else. Thank's for your continues tests with the latest builds. I will forward this discussion to the netsurf user list. Some "lags" where always present, and I don't know what it is. It happens every now and then - especially on some pages. So it is more or less reproducible. However. Because people complained, I have set the GUI priority to "Low" again. That means the Browser is less responsive, less time is spent on checking User Interactions. That gives a bit more time for rendering. But the user can modify this setting now. Go into the Choices menu and select some value for "GUI timeout" - that's the timeout value passed to evnt_multi. Selest "10" and see if it makes the GUI more responsive, as example: for clicking scroll button. Btw. since libdom is used (2.9 used libxml) css matching got slower. Maybe that's the speed issue that was recognized a few days ago. Hower, libdom is used since several month now So that's nothing new ;) Also make sure to unzip the whole archive, many things where modified. Greets, Ole --
Re: BBC website
Am Donnerstag, den 07.11.2013, 21:08 +0100 schrieb Jean-François Lemaire : I compared with version 2.9 available on your website and it is roughly 2 times slower on most webpages. I have to do 2 things... build a version completly optimized for coldfire (I think the buildsystem only optimizes the frontend for coldfire, but not the libs). and add a user option "priority" -> GUI or Rendering (I can't decide for you ;)). Greets, Ole
Re: BBC website
Am Mittwoch, den 23.10.2013, 21:56 +0200 schrieb Jean-François Lemaire : On Wednesday 23 October 2013 20:37:03 Peter Young wrote: On 23 Oct 2013 Peter Slegg wrote: > I noticed some of the headlines on the BBC website are over-written: > > http://www.bbc.co.uk/news/ The Atari Build 1381 seems OK to me, though it took 63 seconds to display the page! Peter, is it as slow on your Milan? Is it worse compared to previous netsurf versions? I changed a time setting to improve GUI responsiveness. I would inspect MiNTLibs malloc() implementation to optimize such pages. Maybe someone is able to trace netsurf performance of the malloc() call behaviour with hatari emulator? I know you can get pretty good graphs out of it... Also using a different malloc() implementation would be interesting to measure with hatari. (of course that would have be configured for the buildsystem of the libs too, not just the netsurf GUI buildsystem) Greets, Ole
Re: netsurf-fb - linux framebuffer
Am Donnerstag, den 31.10.2013, 15:08 +0100 schrieb Andrés Martinelli : How can I start netsurf with the linux "surface", so it uses the terminal framebuffer instead of tty7/tty8 ??? Hello, you can use -f=linux or maybe -f linux That should work, at least in the source tells it looks that way: http://git.netsurf-browser.org/netsurf.git/tree/framebuffer/gui.c#n437 Greets, Ole
Re: Atari daily build 1391
Am Dienstag, den 15.10.2013, 23:23 +0200 schrieb Peter Slegg : "CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!" Did you also update the resource file? Anyway, the resource file is a bit odd right now, the throbber has white background, instead of transparent. I once used that for "debugging" something and forgot to remove it again. Anyway, AFAIK the resource file should work fine. So please make sure you unpacked it to the correct place. Greets, Ole
Re: Daily build 1374 - crash on Yahoo
Am Samstag, den 05.10.2013, 23:38 +0200 schrieb Ole : However, I logged into Yahoo.co.uk and when I moved the focus to the home page search field, Netsurf crashed out. I repeated the test to be sure. This doesn't happen with my custom builds. So maybe it's caused by optimization flags or the GCC Version in use... or maybe it was just an lost bit ;) I switched to head again... and now I saw the bug. It even smashed aranym. This probably an bug inside the core of netsurf, introduced in the last 10 days. There were some textarea changes regarding undo/redo. The problem is: I can not reproduce it all the time.
Re: Daily build 1374 - crash on Yahoo
However, I logged into Yahoo.co.uk and when I moved the focus to the home page search field, Netsurf crashed out. I repeated the test to be sure. This doesn't happen with my custom builds. So maybe it's caused by optimization flags or the GCC Version in use... or maybe it was just an lost bit ;) I will keep an eye on it.
Re: Atari daily build 1344
(2.23) desktop/global_history.c global_history_init 715: Loading global history ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion `win != ((void *)0)' failed. Should be fixed in the next auto-build. Greets, Ole
Re: Atari daily build 1344
Hello Peter, I am running from /u/g/Applicatiions/netsurf as I always do. Below id th result of running with -v Strangely I cannot pipe this output to a file. You have to pipe the error output, not stdout. I believe it's done like this: ns.prg &> ns.log (2.23) desktop/global_history.c global_history_init 715: Loading global history ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion `win != ((void *)0)' failed. ( I think the problem is related to the changes to the TreeView. I will have a look at it. Thanks for testing the daily builds and reporting the problem. Greets, Ole
Re: Atari daily build 1344
Am Montag, den 09.09.2013, 14:17 +0200 schrieb Peter Slegg : I have just tride the 1344 daily build and it fails to start saying it can't find netsurf.rsc There is an problem with some atari desktops and drive letters / resource location. Did you try to run netsurf from the unified filesystem (U:) ? If not, please do so and report the results, thanks. Greets, Ole
Re: Redraws
Hello, Am Samstag, den 06.07.2013, 12:44 +0200 schrieb Jean-François Lemaire : This is a well known issue. In my understanding it only flickers because of the animated GIFs. Disable animations in Choices and the page should no longer flicker. This is a long standing bug in libnsgif (the GIF parsing and rendering lib used by NetSurf) or netsurf itself. It updates the wrong screen areas (instead of the GIF's area). This only happens on the atari-forum.com page. At least I have never seen another page. Maybe someone can copy the animated gif into an page that has no other elements otherwise (except a little bit of text to see flickering...) and check if it still flickering because it updates the wrong area. If not, the problem seems to be triggered by the page structure, not the GIF's. Greets, Ole
Re: techradar fails to display
Am Montag, den 13.05.2013, 21:07 +0200 schrieb cj : This happens on a number of pages - ie jsoff is fine but json displays nothing or parts of the page are missing. I assume it means that when a server sends a js page, it is too complex for NetSurf to parse and hence goes awry, whereas if the non-js page is sent, that displays fine. Yes, I think this describes the problem very well, except one thing: netsurf probably doesn't fail to parse the js. But once the js code get's executed, it hit's the problem that netsurf doesn't implement much of the DOM binding, or other browser specific additions to javascript (like ajax, for example). Greets, Ole
Re: Text area refresh
Am Mittwoch, den 10.04.2013, 22:11 +0200 schrieb Peter Slegg : I don't know if it related but the Page Up key does a page-down action. Not related, but should be fixed in the next auto-build.
Re: Text area refresh
Am Montag, den 08.04.2013, 23:52 +0200 schrieb Ole : Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris Young" I have to think about how to solve it...: 1. I would still like to process menu events before browser_window events. 2. catching ctrl+v and not passing it to the core is maybe incorrect(??). What looks best suited to me is to drop events which are handled by the menu area (should be done already, so this is an bug in the frontend), however, that solution maybe conflicts with policy number 2 (see above). I was wrong, browser_window_key_input is called before the deskmenu shortcut processing, so now I'm ignoring inputs which are handled by browser_window_key_input. The problem should be fixed in the next build, I hope this doesn't introduce any side-effects :) Greets, Ole
Re: Text area refresh
Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris Young"
:
Oh yes, I didn't realise KEY_PASTE = ASCII 22 = Ctrl-V (until I
looked
it up)
I still think the double-pasting would be the frontend interpreting
it
directly as a KEY_PASTE *and* passing the original key press as well.
The following is happening with the Atari frontend:
- First Ctrl+V is captured by the main menu... ("paste" action is
executed).
- The browser window key handling routine passes the keycode to the
internal browser_window structure.
I have to think about how to solve it...:
1. I would still like to process menu events before
browser_window events.
2. catching ctrl+v and not passing it to the core is maybe
incorrect(??).
What looks best suited to me is to drop events which are handled by the
menu area (should be done already,
so this is an bug in the frontend), however, that solution maybe
conflicts with policy number 2 (see above).
Greets,
Ole
Re: Text area refresh
Am Donnerstag, den 21.03.2013, 20:25 +0100 schrieb Jean-François Lemaire I tried the Atari build and indeed it is much better now. It would be fantastic if multi-line textareas could be improved in the same way. Thanks for this! Yes, typing results in no flickering now. Thanks!
Re: Request for feedback
Hello, I just tried the latest version and on the page http://www.heise.de some article-previews are displayed with scrollbars. Otherwise I did not encounter any new or big problems, but I did much testing. Greets, Ole -- ---
Re: Performance on Debian Linux
Am Sonntag, den 26.08.2012, 11:05 +0200 schrieb Wendell P : Yea, it's still 6s with about:config. Why should fetching the favicon take so long? DNS, network layer setup, network latency... At least it's clear that the first/single network access takes that long. Thanks for reporting it. I believe you could also try to use a proxy to cache the network access. Greets, Ole
Re: Performance on Debian Linux
Am Sonntag, den 26.08.2012, 09:19 +0200 schrieb Wendell P : Tried it several times, still 6s. If it helps, while Firefox and Chrome are faster, w3m is also very slow on my machine. Here is "netsurf -v about:blank 2>logfile" Looks like it is not good to try about:blank. It still has network access involved: (0.575378) content/fetchers/curl.c fetch_curl_setup 365: fetch 0x8cd9458, url 'http://www.google.com/favicon.ico' Please try about:config. Greets, Ole
Re: Performance on Debian Linux
Am Samstag, den 25.08.2012, 09:43 +0200 schrieb Wendell P : > On my machine, Chrome and Firefox each take 3s to boot, while Netsurf > takes 6s. Is this typical or do you think there is something wrong? Hello, can you please test with an blank or at least simple *local* webpage? I believe it's about the network layer within netsurf or your network might be slow. AFAIK mozilla etc. load a local page at startup - and even if it is remote - it's probably cached. Netsurf has no disk cache yet. Please test it and tell us the results, thanks :) ! Greets, Ole
Re: Deleting subset of cookies
Hello, Am Sonntag, den 10.06.2012, 12:56 +0200 schrieb Harriet Bazley : http://sourceforge.net/tracker/?func=detail&aid=3324329&group_id=51719&atid=464312 have to go through the process of opening the log-in page and then selecting and deleting the site-specific cookies in order to be able to view the members-only http://www.ravelry.com - is there a way of automating this process (i.e. selecting and deleting a subset of the cookies file)? I'm not sure if this is an real option, especially when you want to do it regularly But I expect the NetSurf cookies file to be in netscape format, which means you can find the lines which contains the domain entries that you want to find... and then just delete those lines with an editor. Not very comfortable... That's true. Greets, m
Re: netsurf-sdl on Windows?
Am Montag, den 07.05.2012, 15:32 +0200 schrieb LM : Hello, Tried out netsurf-sdl on Debian and was attempting to figure out if something similar could be built on Windows. I invoked the make file with: make target=windows That's wrong. The framebuffer isn't OS specific, you still have to build it this way: make TARGET=framebuffer the "make TARGET=windows" will attempt to build the native windows executable. Would be good if you could get both builds to work under windows. :) The framebuffer library "libnsfb" requires X11 libraries... I once submitted a patch to the list that disables specific libnsfb backends. Just remove the X and maybe other not-so-important dependencies from the libnsfb makefiles and you should be able to compile the lib. After you have installed libnsfb, you should be able to link framebuffer-sdl for windows. Greets, Ole
