On 30 Jun, Christopher Dewhurst wrote in message
<0f86116453.crisPi@cdewhurst2010.btinternet.com>:
> In message <mpro.mp5l7i03cirzk01ob.lists@stevefryatt.org.uk>
> Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>
> > Probably not a good approach for the long term, as the disc map clearly
> > isn't very happy. I'd endorse the advice to check/fix the disc with
> > DiscKnight, before doing much else with the system.
>
> thanks for the tips. Running DiscKnight does indeed report errors within
> !Boot.Choices.WWW.Netsurf. I think an investment in the full version may
> be in order (I think the "Repair" option is disabled on the free version).
>
> Although RISC OS threw a wobbler in the process,renaming
> Choices.WWW.Netsurf to "zzzz" seemed to work for the time being.
Just be aware that if your disc map is corrupted, then you've no real idea
if it's saving new or modified files over existing files that you'd quite
like to keep. If DiscKnight is reporting errors, personally I would stop
using the system until the map had been fixed.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Sunday, 30 June 2013
Re: Broken directory
In message <mpro.mp5l7i03cirzk01ob.lists@stevefryatt.org.uk>
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> On 28 Jun, John Williams wrote in message
> <53630be066JohnRW@ukgateway.net>:
>> In article <7f76f76253.crisPi@cdewhurst2010.btinternet.com>,
>> Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
>>
>>> Not sure if this is a Netsurf or RISC OS specific thing but I noticed
>>> Netsurf was reverting to default choices and losing its hotlist. I
>>> looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory" if
>>> I try to delete or move it.
>>
>>> Any way out?
>>
>> If you can rename it to, say, "zzzz" so it gets put out of the way at the
>> bottom of the filer display, you could create a new empty directory to
>> populate.
> Probably not a good approach for the long term, as the disc map clearly
> isn't very happy. I'd endorse the advice to check/fix the disc with
> DiscKnight, before doing much else with the system.
thanks for the tips. Running DiscKnight does indeed report errors
within !Boot.Choices.WWW.Netsurf. I think an investment in the full
version may be in order (I think the "Repair" option is disabled on
the free version).
Although RISC OS threw a wobbler in the process,renaming
Choices.WWW.Netsurf to "zzzz" seemed to work for the time being.
thanks,
Chris
--
Christopher Dewhurst
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> On 28 Jun, John Williams wrote in message
> <53630be066JohnRW@ukgateway.net>:
>> In article <7f76f76253.crisPi@cdewhurst2010.btinternet.com>,
>> Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
>>
>>> Not sure if this is a Netsurf or RISC OS specific thing but I noticed
>>> Netsurf was reverting to default choices and losing its hotlist. I
>>> looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory" if
>>> I try to delete or move it.
>>
>>> Any way out?
>>
>> If you can rename it to, say, "zzzz" so it gets put out of the way at the
>> bottom of the filer display, you could create a new empty directory to
>> populate.
> Probably not a good approach for the long term, as the disc map clearly
> isn't very happy. I'd endorse the advice to check/fix the disc with
> DiscKnight, before doing much else with the system.
thanks for the tips. Running DiscKnight does indeed report errors
within !Boot.Choices.WWW.Netsurf. I think an investment in the full
version may be in order (I think the "Repair" option is disabled on
the free version).
Although RISC OS threw a wobbler in the process,renaming
Choices.WWW.Netsurf to "zzzz" seemed to work for the time being.
thanks,
Chris
--
Christopher Dewhurst
Saturday, 29 June 2013
Re: Broken directory
In article <20130629072100.GC8610@pepperfish.net>,
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Jun 28, 2013 at 04:45:04PM +0000, Christopher Dewhurst wrote:
> > Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> > Netsurf was reverting to default choices and losing its hotlist. I
> > looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
> > if I try to delete or move it.
> >
> > Any way out?
> >
> > (Using NS 3.1 Dev #1264 on Raspberry Pi but I think the problem has
> > been around for a week or two)
> Your file system is broken. This is a RISC OS problem as FileCore is
> delicate to crashes and power outages. Either rename it out of the way,
> reformat/restart the whole thing, or invest in Dave Ruck's excellent
> !Disknight to fix the problem.
Very well worthwhile. It's only £10.
http://www.armclub.org.uk/products/discknight/
Cheers,
--
Chris
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Jun 28, 2013 at 04:45:04PM +0000, Christopher Dewhurst wrote:
> > Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> > Netsurf was reverting to default choices and losing its hotlist. I
> > looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
> > if I try to delete or move it.
> >
> > Any way out?
> >
> > (Using NS 3.1 Dev #1264 on Raspberry Pi but I think the problem has
> > been around for a week or two)
> Your file system is broken. This is a RISC OS problem as FileCore is
> delicate to crashes and power outages. Either rename it out of the way,
> reformat/restart the whole thing, or invest in Dave Ruck's excellent
> !Disknight to fix the problem.
Very well worthwhile. It's only £10.
http://www.armclub.org.uk/products/discknight/
Cheers,
--
Chris
Re: Broken directory
On 28 Jun, John Williams wrote in message
<53630be066JohnRW@ukgateway.net>:
> In article <7f76f76253.crisPi@cdewhurst2010.btinternet.com>,
> Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
>
> > Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> > Netsurf was reverting to default choices and losing its hotlist. I
> > looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory" if
> > I try to delete or move it.
>
> > Any way out?
>
> If you can rename it to, say, "zzzz" so it gets put out of the way at the
> bottom of the filer display, you could create a new empty directory to
> populate.
Probably not a good approach for the long term, as the disc map clearly
isn't very happy. I'd endorse the advice to check/fix the disc with
DiscKnight, before doing much else with the system.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<53630be066JohnRW@ukgateway.net>:
> In article <7f76f76253.crisPi@cdewhurst2010.btinternet.com>,
> Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
>
> > Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> > Netsurf was reverting to default choices and losing its hotlist. I
> > looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory" if
> > I try to delete or move it.
>
> > Any way out?
>
> If you can rename it to, say, "zzzz" so it gets put out of the way at the
> bottom of the filer display, you could create a new empty directory to
> populate.
Probably not a good approach for the long term, as the disc map clearly
isn't very happy. I'd endorse the advice to check/fix the disc with
DiscKnight, before doing much else with the system.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Bed page display
In article <5362eae127Lists@Torrens.org.uk>, Richard Torrens (lists)
<Lists@Torrens.org.uk> wrote:
> http://www.cornishworkshop.co.uk/hammerhandle.html
> is a series of nested tgbles.
Yes, but not the problem, I think.
> The text overwrites, all on one line, with no proper wrapping in the
> cells.
I suspect this is because the page uses a CSS file which includes
body {line-height:0;.......
A line-height of 0 is obviously undesirable and it is not reset to
override this for the other elements used on the page, AFAICS.
You can see it pretty much as intended if you save the web page to RAM
disc and run it from there. As it can't find the 'faulty' CSS file from
its relative URL, it is ignored.
To see it more as intended you can use this link to load the 'invisible'
css file http://www.cornishworkshop.co.uk/candyedit.css . Save it to ram
disc alongside the web page as candyedit/css then edit it and delete
"line-height:0;" in the first line. Save it. The page then displays
pretty much as intended. Luckily, the images use absolute references.
A good example of 'sledgehammer to crack nut' use of CSS as it adds
almost nothing worthwhile to the page content whatsoever.
<Lists@Torrens.org.uk> wrote:
> http://www.cornishworkshop.co.uk/hammerhandle.html
> is a series of nested tgbles.
Yes, but not the problem, I think.
> The text overwrites, all on one line, with no proper wrapping in the
> cells.
I suspect this is because the page uses a CSS file which includes
body {line-height:0;.......
A line-height of 0 is obviously undesirable and it is not reset to
override this for the other elements used on the page, AFAICS.
You can see it pretty much as intended if you save the web page to RAM
disc and run it from there. As it can't find the 'faulty' CSS file from
its relative URL, it is ignored.
To see it more as intended you can use this link to load the 'invisible'
css file http://www.cornishworkshop.co.uk/candyedit.css . Save it to ram
disc alongside the web page as candyedit/css then edit it and delete
"line-height:0;" in the first line. Save it. The page then displays
pretty much as intended. Luckily, the images use absolute references.
A good example of 'sledgehammer to crack nut' use of CSS as it adds
almost nothing worthwhile to the page content whatsoever.
Re: Broken directory
On Fri, Jun 28, 2013 at 04:45:04PM +0000, Christopher Dewhurst wrote:
> Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> Netsurf was reverting to default choices and losing its hotlist. I
> looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
> if I try to delete or move it.
>
> Any way out?
>
> (Using NS 3.1 Dev #1264 on Raspberry Pi but I think the problem has
> been around for a week or two)
Your file system is broken. This is a RISC OS problem as FileCore is
delicate to crashes and power outages. Either rename it out of the way,
reformat/restart the whole thing, or invest in Dave Ruck's excellent
!Disknight to fix the problem.
B.
> Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> Netsurf was reverting to default choices and losing its hotlist. I
> looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
> if I try to delete or move it.
>
> Any way out?
>
> (Using NS 3.1 Dev #1264 on Raspberry Pi but I think the problem has
> been around for a week or two)
Your file system is broken. This is a RISC OS problem as FileCore is
delicate to crashes and power outages. Either rename it out of the way,
reformat/restart the whole thing, or invest in Dave Ruck's excellent
!Disknight to fix the problem.
B.
Friday, 28 June 2013
Re: Broken directory
In article <7f76f76253.crisPi@cdewhurst2010.btinternet.com>,
Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
> Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> Netsurf was reverting to default choices and losing its hotlist. I
> looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
> if I try to delete or move it.
> Any way out?
If you can rename it to, say, "zzzz" so it gets put out of the way at the
bottom of the filer display, you could create a new empty directory to
populate.
John
Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
> Not sure if this is a Netsurf or RISC OS specific thing but I noticed
> Netsurf was reverting to default choices and losing its hotlist. I
> looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
> if I try to delete or move it.
> Any way out?
If you can rename it to, say, "zzzz" so it gets put out of the way at the
bottom of the filer display, you could create a new empty directory to
populate.
John
Broken directory
Not sure if this is a Netsurf or RISC OS specific thing but I noticed
Netsurf was reverting to default choices and losing its hotlist. I
looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
if I try to delete or move it.
Any way out?
(Using NS 3.1 Dev #1264 on Raspberry Pi but I think the problem has
been around for a week or two)
thanks
--
Christopher Dewhurst
Netsurf was reverting to default choices and losing its hotlist. I
looked at !Boot.Choices.WWW.Netsurf which reports "Broken directory"
if I try to delete or move it.
Any way out?
(Using NS 3.1 Dev #1264 on Raspberry Pi but I think the problem has
been around for a week or two)
thanks
--
Christopher Dewhurst
Bed page display
http://www.cornishworkshop.co.uk/hammerhandle.html
is a series of nested tgbles.
The text overwrites, all on one line, with no proper wrapping in the cells.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
is a series of nested tgbles.
The text overwrites, all on one line, with no proper wrapping in the cells.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Re: Get/set form elements from frontend?
On Thu, Jun 27, 2013 at 20:05:50 +0100, Chris Young wrote:
> Is it possible, now we have DOM, to get the IDs of all form elements
> on a page and get/set thir contents?
We first need to rewrite the form handling part of NetSurf itself. We need to
be making our "gadgets" manage their data via the DOM and make the form
submission happen via the DOM too. At that point, anything outside of the
render core updating the DOM will be possible and thus your idea could start to
bear fruit.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> Is it possible, now we have DOM, to get the IDs of all form elements
> on a page and get/set thir contents?
We first need to rewrite the form handling part of NetSurf itself. We need to
be making our "gadgets" manage their data via the DOM and make the form
submission happen via the DOM too. At that point, anything outside of the
render core updating the DOM will be possible and thus your idea could start to
bear fruit.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Thursday, 27 June 2013
Get/set form elements from frontend?
Is it possible, now we have DOM, to get the IDs of all form elements
on a page and get/set thir contents?
I'm thinking of from frontend code here, so a form or password manager
could potentially be written (I'm not thinking of writing one, just
whether I can put things in place so an external one is possible).
Chris
on a page and get/set thir contents?
I'm thinking of from frontend code here, so a form or password manager
could potentially be written (I'm not thinking of writing one, just
whether I can put things in place so an external one is possible).
Chris
Wednesday, 26 June 2013
Hooks for helper applications
Does NetSurf broadcast wimp messages that could be used by helper
applications? It would be nice to be be able to set keys for
entering usernames and passwords dynamically; a message giving
the url of the page that currently has the input focus would
be useful.
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
applications? It would be nice to be be able to set keys for
entering usernames and passwords dynamically; a message giving
the url of the page that currently has the input focus would
be useful.
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
Sunday, 23 June 2013
[Rpcemu] RPCEmu at Silicon Dreasm/VCF2 5-7 July 2013
There will be a RPCEmu presence on the ROUGOL (RISC OS Users Group Of
London) stand at next months Silicon Dreams/Vintage Computer Festival GB
in Coalville, Leicestershire.
http://www.silicondreams.org.uk/
In addition to RPCEmu, there will be a Risc PC to compare it with, and the
rest of the ROUGOL stand will be demostrating BeagleBoards, PandaBoards
and the Raspberry Pi.
One final special guest on the stand will be what is believed to be the
only working Phoebe (Risc PC 2) in the world.
If you can make it, come along and introduce yourself!
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
London) stand at next months Silicon Dreams/Vintage Computer Festival GB
in Coalville, Leicestershire.
http://www.silicondreams.org.uk/
In addition to RPCEmu, there will be a Risc PC to compare it with, and the
rest of the ROUGOL stand will be demostrating BeagleBoards, PandaBoards
and the Raspberry Pi.
One final special guest on the stand will be what is believed to be the
only working Phoebe (Risc PC 2) in the world.
If you can make it, come along and introduce yourself!
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] JPEG rendering issues
In general use I find RPCEmu very satisfactory, the only downside
compared with my Iyonix being generally slower JPEG rendering
(!Thump-Viewer-Slideshow runs about half as fast), despite general
system performance being considerably quicker. The worst instance is
when displaying two typical DSC JPEGs (4-5 MB) for comparison using
!Thump, and dragging one across the other, resulting in tedious 'black
striping' and image redrawing. 5.19 is better than 4.02 (presumably
due to being fully 32-bit), but still not as good as the Iyonix. I
appreciate that the comparison is unfair inasmuch as the Iyonix has
dedicated graphics hardware, but on the other hand RPCEmu's memory
speed on my system is massively (>3000%) faster than the Iyo according
to ROMark.
As it happens, image redrawing is being discussed in a thread on
netsurf-users
http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2013-June/011962.html
in which RO Select's cached screen memory and better JPEG routines are
mentioned.
I know that several of us are using RO 4.39 and 6.20 on RPCEmu - can
anybody confirm that JPEG display and screen redrawing is improved,
compared with 4.02?
George
[Base system: Win7/64-bit, Intel Core i7 quad-core 3.4GHz processor,
4GB RAM.]
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
compared with my Iyonix being generally slower JPEG rendering
(!Thump-Viewer-Slideshow runs about half as fast), despite general
system performance being considerably quicker. The worst instance is
when displaying two typical DSC JPEGs (4-5 MB) for comparison using
!Thump, and dragging one across the other, resulting in tedious 'black
striping' and image redrawing. 5.19 is better than 4.02 (presumably
due to being fully 32-bit), but still not as good as the Iyonix. I
appreciate that the comparison is unfair inasmuch as the Iyonix has
dedicated graphics hardware, but on the other hand RPCEmu's memory
speed on my system is massively (>3000%) faster than the Iyo according
to ROMark.
As it happens, image redrawing is being discussed in a thread on
netsurf-users
http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2013-June/011962.html
in which RO Select's cached screen memory and better JPEG routines are
mentioned.
I know that several of us are using RO 4.39 and 6.20 on RPCEmu - can
anybody confirm that JPEG display and screen redrawing is improved,
compared with 4.02?
George
[Base system: Win7/64-bit, Intel Core i7 quad-core 3.4GHz processor,
4GB RAM.]
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 22 June 2013
Re: Slow image display
In message <535dae1be8tim@timil.com>
Tim Hill <tim@timil.com> wrote:
> In article <6719835d53.bryan@helpful.demon.co.uk>, Bryan Hogan
>> because the OS JPEG routines, as used in SwiftJPEG for example, can
>> display it at any scale in about one second.
> One second? Wow. Is that to repaint the whole window? Should've bought me
> an Omega.
:-) A more accurate timing reveals it to be 1.2s
> This Iyonix is taking about 4 seconds with Geminus (6.5 without) to
> display from RAMFS (whatever the quality setting) in SwiftJPEG.
I guess it is partly due to the Omega having the video memory in main
RAM rather than having to go across the PCI bus like the Iyonix, and
also the improvements in RO Select (cached screen memory, better JPEG
routines).
> I was just trying to demonstrate that NetSurf's lack of speed is not unique
While I'm not surprised that NetSurf's routines are slower than those
in RISC OS, a whole order of magnitude slower is surprising!
> That NetSurf doesn't seem to cache for very long a smaller version of the
> image that is painted into the window may seem odd
Is it a bug that NetSurf throws away the memory used by an image that
is still on screen? That results in multiple slow redraws rather than
just the initial ones.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
Tim Hill <tim@timil.com> wrote:
> In article <6719835d53.bryan@helpful.demon.co.uk>, Bryan Hogan
>> because the OS JPEG routines, as used in SwiftJPEG for example, can
>> display it at any scale in about one second.
> One second? Wow. Is that to repaint the whole window? Should've bought me
> an Omega.
:-) A more accurate timing reveals it to be 1.2s
> This Iyonix is taking about 4 seconds with Geminus (6.5 without) to
> display from RAMFS (whatever the quality setting) in SwiftJPEG.
I guess it is partly due to the Omega having the video memory in main
RAM rather than having to go across the PCI bus like the Iyonix, and
also the improvements in RO Select (cached screen memory, better JPEG
routines).
> I was just trying to demonstrate that NetSurf's lack of speed is not unique
While I'm not surprised that NetSurf's routines are slower than those
in RISC OS, a whole order of magnitude slower is surprising!
> That NetSurf doesn't seem to cache for very long a smaller version of the
> image that is painted into the window may seem odd
Is it a bug that NetSurf throws away the memory used by an image that
is still on screen? That results in multiple slow redraws rather than
just the initial ones.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
Wednesday, 19 June 2013
Re: Add support for parsing writing-mode property v1
In article <DA20EE2B-0DB9-4C88-9389-A14C8695F5C7@defpixel.com>,
Caitlin Potter <snowball@defpixel.com> wrote:
> I just realized I've forgotten to attach the current version of the
> writing-mode property patch, so here :>
Thanks for the patch.
I've attached a new version. The changes are:
+ Whitespace fixes
+ Added the writing-mode property handler to the handler table
(The /src/parse/properties/properties.c change)
+ Moved the WRITING_MODE propstring, so the property propstrings are
in alphabetical order.
+ Added the computed style accessor for writing-mode
(The /include/libcss/computed.h and /src/select/computed.c changes)
+ Added parser tests for the writing-mode property's bytecode
(The /test/data/parse/properties.dat change)
+ Added some illegal value handling tests for writing-mode property
(The /test/data/parse2/illegal-values.dat change)
+ Updated the test code to dump writing-mode property
(The /test/dump.h and /test/dump_computed.h changes)
+ Updated the select test data for writing-mode.
This currently fails on a test that doesn't set writing-mode, but the
default value in the expected and test result don't match.
The test data expects "writing-mode: inherit" but gets
"writing-mode: vertical-rl".
Seems to be something to do with uncommon property defaults.
> I could use some guidance writing parse/select tests for the property
> because even after studying the test programs and data files, it's not
> really obvious what the system is
The parse ones are quite simple. A rule is set in the #data section.
Then in the #expected section, you write the bytecode you expect. So
for
writing-mode: vertical-lr ! important
>From docs/Bytecode:
<opcode+flags+value> is 32 bits wide:
bits 18-31: value
bits 10-17 : flags
bits 0-9 : opcode
The 8 bits of flag data are defined as follows:
bits 2-7: Must Be Zero (MBZ)
bit 1 : value is inherit
bit 0 : value is important
...
6f - writing-mode
<value> (14bits) :
bits 8-13: MBZ
bits 0-7 :
00000000 => horizontal-tb,
00000001 => vertical-rl,
00000010 => vertical-lr,
other => Reserved for future expansion.
The opcode for writing-mode is 6f, we have important set, so bit 0 of
flags is set, and for value we have vertical-lr, so 0b00000010.
The expected result is those components stitched together and expressed in
hex:
0x0008046f
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Caitlin Potter <snowball@defpixel.com> wrote:
> I just realized I've forgotten to attach the current version of the
> writing-mode property patch, so here :>
Thanks for the patch.
I've attached a new version. The changes are:
+ Whitespace fixes
+ Added the writing-mode property handler to the handler table
(The /src/parse/properties/properties.c change)
+ Moved the WRITING_MODE propstring, so the property propstrings are
in alphabetical order.
+ Added the computed style accessor for writing-mode
(The /include/libcss/computed.h and /src/select/computed.c changes)
+ Added parser tests for the writing-mode property's bytecode
(The /test/data/parse/properties.dat change)
+ Added some illegal value handling tests for writing-mode property
(The /test/data/parse2/illegal-values.dat change)
+ Updated the test code to dump writing-mode property
(The /test/dump.h and /test/dump_computed.h changes)
+ Updated the select test data for writing-mode.
This currently fails on a test that doesn't set writing-mode, but the
default value in the expected and test result don't match.
The test data expects "writing-mode: inherit" but gets
"writing-mode: vertical-rl".
Seems to be something to do with uncommon property defaults.
> I could use some guidance writing parse/select tests for the property
> because even after studying the test programs and data files, it's not
> really obvious what the system is
The parse ones are quite simple. A rule is set in the #data section.
Then in the #expected section, you write the bytecode you expect. So
for
writing-mode: vertical-lr ! important
>From docs/Bytecode:
<opcode+flags+value> is 32 bits wide:
bits 18-31: value
bits 10-17 : flags
bits 0-9 : opcode
The 8 bits of flag data are defined as follows:
bits 2-7: Must Be Zero (MBZ)
bit 1 : value is inherit
bit 0 : value is important
...
6f - writing-mode
<value> (14bits) :
bits 8-13: MBZ
bits 0-7 :
00000000 => horizontal-tb,
00000001 => vertical-rl,
00000010 => vertical-lr,
other => Reserved for future expansion.
The opcode for writing-mode is 6f, we have important set, so bit 0 of
flags is set, and for value we have vertical-lr, so 0b00000010.
The expected result is those components stitched together and expressed in
hex:
0x0008046f
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Tuesday, 18 June 2013
Re: Slow image display
In article <535db2eba3john@jaharrison.me.uk>, John Harrison
<john@jaharrison.me.uk> wrote:
> > I imagine that a user was never expected to post something so huge.
> But many people who take and transmit photos have no concept of file
> size, including people who contribute to (or manage) websites.
True.
> Software that automatically scales pictures to fit the context (and
> intrinsically helpful thing to do) aggravate the problem by hiding from
> them the consequences of what they are doing.
Indeed. Hence my earlier posting with an appropriate PHP link
<535d31f650tim@timil.com>
<john@jaharrison.me.uk> wrote:
> > I imagine that a user was never expected to post something so huge.
> But many people who take and transmit photos have no concept of file
> size, including people who contribute to (or manage) websites.
True.
> Software that automatically scales pictures to fit the context (and
> intrinsically helpful thing to do) aggravate the problem by hiding from
> them the consequences of what they are doing.
Indeed. Hence my earlier posting with an appropriate PHP link
<535d31f650tim@timil.com>
Re: Slow image display
> I imagine that a user was never expected to post something so huge.
But many people who take and transmit photos have no concept of file size,
including people who contribute to (or manage) websites.
Software that automatically scales pictures to fit the context (and
intrinsically helpful thing to do) aggravate the problem by hiding from
them the consequences of what they are doing.
Regards
--
John Harrison
Website http://jaharrison.me.uk
But many people who take and transmit photos have no concept of file size,
including people who contribute to (or manage) websites.
Software that automatically scales pictures to fit the context (and
intrinsically helpful thing to do) aggravate the problem by hiding from
them the consequences of what they are doing.
Regards
--
John Harrison
Website http://jaharrison.me.uk
[Rpcemu] RO 5.21
For the record: RO 5.21 (16-Jun-13) using !Boot, from HardDisc4 of the
same date, runs here with RPCEmu 0.8.10, on Win7 32bit. No problem.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
same date, runs here with RPCEmu 0.8.10, on Win7 32bit. No problem.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Slow image display
In article <6719835d53.bryan@helpful.demon.co.uk>, Bryan Hogan
<netsurf@helpful.demon.co.uk> wrote:
> In message <535d31f650tim@timil.com> Tim Hill <tim@timil.com> wrote:
> > In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
> > <netsurf@helpful.demon.co.uk> wrote:
[Snip]
> > I don't think its entirely a NetSurf issue or a memory size issue but
> > a processor speed
> Not simply a processor speed issue
No, indeed. Which is why I wrote what I did.
> because the OS JPEG routines, as
> used in SwiftJPEG for example, can display it at any scale in about
> one second.
One second? Wow. Is that to repaint the whole window? Should've bought me
an Omega. This Iyonix is taking about 4 seconds with Geminus (6.5
without) to display from RAMFS (whatever the quality setting) in
SwiftJPEG.
I was just trying to demonstrate that NetSurf's lack of speed is not
unique and various apps - such as ChangeFSI, which is 'slow' for
different reasons - would be improved with a quicker clock. So would
SwiftJPEG!
That NetSurf doesn't seem to cache for very long a smaller version of the
image that is painted into the window may seem odd but web (content
management) designers shouldn't be scaling something to about 1/10 of its
size to display it on a web page. I imagine that a user was never
expected to post something so huge. It is, after all, over 1.3m² at 90
dpi.
If the poster had posted a small version of the photo and a link to the
larger one this issue would never had arisen. But then if the
photographer had the opportunity to illuminate the subject better it
would have been easier to examine. ;-)
<netsurf@helpful.demon.co.uk> wrote:
> In message <535d31f650tim@timil.com> Tim Hill <tim@timil.com> wrote:
> > In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
> > <netsurf@helpful.demon.co.uk> wrote:
[Snip]
> > I don't think its entirely a NetSurf issue or a memory size issue but
> > a processor speed
> Not simply a processor speed issue
No, indeed. Which is why I wrote what I did.
> because the OS JPEG routines, as
> used in SwiftJPEG for example, can display it at any scale in about
> one second.
One second? Wow. Is that to repaint the whole window? Should've bought me
an Omega. This Iyonix is taking about 4 seconds with Geminus (6.5
without) to display from RAMFS (whatever the quality setting) in
SwiftJPEG.
I was just trying to demonstrate that NetSurf's lack of speed is not
unique and various apps - such as ChangeFSI, which is 'slow' for
different reasons - would be improved with a quicker clock. So would
SwiftJPEG!
That NetSurf doesn't seem to cache for very long a smaller version of the
image that is painted into the window may seem odd but web (content
management) designers shouldn't be scaling something to about 1/10 of its
size to display it on a web page. I imagine that a user was never
expected to post something so huge. It is, after all, over 1.3m² at 90
dpi.
If the poster had posted a small version of the photo and a link to the
larger one this issue would never had arisen. But then if the
photographer had the opportunity to illuminate the subject better it
would have been easier to examine. ;-)
Re: Slow image display
Bryan Hogan, on 18 Jun, wrote:
> In message <535d31f650tim@timil.com>
> Tim Hill <tim@timil.com> wrote:
>
> > In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
> > <netsurf@helpful.demon.co.uk> wrote:
> > > Visiting this page with NetSurf build #1257 on my Omega (300MHz
> > > StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
>
> >> http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
>
> > Displaying a 5109x3387 full colour image at 600x398 (or whatever it is)
> > is considered 'bad form' and obviously requires the image to be resized
> > each time NetSurf displays it onscreen. Perhaps NetSurf should be
> > caching the smaller version it creates for longer?
>
> Yes, that would help.
>
> > How long does it take for ChangeFSI to resize it to 600x398? About a
> > minute on this Iyonix.
>
> I don't know, the version (1.27) of ChangeFSI I have crashes on this
> picture!
With ChangeFSI 1.27, VRPC OS4.39, the initial error is "Internal error:
abort on data transfer at &03819444".
This issue with large images has cropped up before. ChangeFSI can be
persuaded to render this large jpeg if a buffer within ChangeFSI is made big
enough. Search for the variable max% and make it bigger. This worked for
me:-
gamma=1:rotate%=FALSE:max%=80000000:bright%=15:lock%=FALSE
A similar ruse does not work for !ChangeFSI 1.34 on the Raspberry Pi which
just exits the iconbar without any error.
--
David Pitt
> In message <535d31f650tim@timil.com>
> Tim Hill <tim@timil.com> wrote:
>
> > In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
> > <netsurf@helpful.demon.co.uk> wrote:
> > > Visiting this page with NetSurf build #1257 on my Omega (300MHz
> > > StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
>
> >> http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
>
> > Displaying a 5109x3387 full colour image at 600x398 (or whatever it is)
> > is considered 'bad form' and obviously requires the image to be resized
> > each time NetSurf displays it onscreen. Perhaps NetSurf should be
> > caching the smaller version it creates for longer?
>
> Yes, that would help.
>
> > How long does it take for ChangeFSI to resize it to 600x398? About a
> > minute on this Iyonix.
>
> I don't know, the version (1.27) of ChangeFSI I have crashes on this
> picture!
With ChangeFSI 1.27, VRPC OS4.39, the initial error is "Internal error:
abort on data transfer at &03819444".
This issue with large images has cropped up before. ChangeFSI can be
persuaded to render this large jpeg if a buffer within ChangeFSI is made big
enough. Search for the variable max% and make it bigger. This worked for
me:-
gamma=1:rotate%=FALSE:max%=80000000:bright%=15:lock%=FALSE
A similar ruse does not work for !ChangeFSI 1.34 on the Raspberry Pi which
just exits the iconbar without any error.
--
David Pitt
Monday, 17 June 2013
Re: Slow image display
In message <535d31f650tim@timil.com>
Tim Hill <tim@timil.com> wrote:
> In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
> <netsurf@helpful.demon.co.uk> wrote:
>> Visiting this page with NetSurf build #1257 on my Omega (300MHz
>> StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
>> http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
> Displaying a 5109x3387 full colour image at 600x398 (or whatever it
> is) is considered 'bad form' and obviously requires the image to be
> resized each time NetSurf displays it onscreen. Perhaps NetSurf should
> be caching the smaller version it creates for longer?
Yes, that would help.
> How long does it take for ChangeFSI to resize it to 600x398? About a
> minute on this Iyonix.
I don't know, the version (1.27) of ChangeFSI I have crashes on this
picture!
> I don't think its entirely a NetSurf issue or a
> memory size issue but a processor speed
Not simply a processor speed issue because the OS JPEG routines, as
used in SwiftJPEG for example, can display it at any scale in about
one second.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
Tim Hill <tim@timil.com> wrote:
> In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
> <netsurf@helpful.demon.co.uk> wrote:
>> Visiting this page with NetSurf build #1257 on my Omega (300MHz
>> StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
>> http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
> Displaying a 5109x3387 full colour image at 600x398 (or whatever it
> is) is considered 'bad form' and obviously requires the image to be
> resized each time NetSurf displays it onscreen. Perhaps NetSurf should
> be caching the smaller version it creates for longer?
Yes, that would help.
> How long does it take for ChangeFSI to resize it to 600x398? About a
> minute on this Iyonix.
I don't know, the version (1.27) of ChangeFSI I have crashes on this
picture!
> I don't think its entirely a NetSurf issue or a
> memory size issue but a processor speed
Not simply a processor speed issue because the OS JPEG routines, as
used in SwiftJPEG for example, can display it at any scale in about
one second.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
Slow image display
In article <c089fb5c53.bryan@helpful.demon.co.uk>, Bryan Hogan
<netsurf@helpful.demon.co.uk> wrote:
> Visiting this page with NetSurf build #1257 on my Omega (300MHz
> StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
> http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
[Snip]
This seems to be the actual image being downloaded:
http://stardot.org.uk/forums//download/file.php?id=6693
It's a pity really that *. don't use PHP to download a more
appropriately-sized image for display on the page, with a link for the
big version for those who want it.
http://www.white-hat-web-design.co.uk/blog/resizing-images-with-php/
Displaying a 5109x3387 full colour image at 600x398 (or whatever it is)
is considered 'bad form' and obviously requires the image to be resized
each time NetSurf displays it onscreen. Perhaps NetSurf should be caching
the smaller version it creates for longer?
> I tried switching the Image options to "Use OS" and the image memory
> up to 100MB but it made no difference.
How long does it take for ChangeFSI to resize it to 600x398? About a
minute on this Iyonix. I don't think its entirely a NetSurf issue or a
memory size issue but a processor speed and an unfortunate web page
authoring issue. A side effect of a CMS no doubt.
<netsurf@helpful.demon.co.uk> wrote:
> Visiting this page with NetSurf build #1257 on my Omega (300MHz
> StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
> http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
[Snip]
This seems to be the actual image being downloaded:
http://stardot.org.uk/forums//download/file.php?id=6693
It's a pity really that *. don't use PHP to download a more
appropriately-sized image for display on the page, with a link for the
big version for those who want it.
http://www.white-hat-web-design.co.uk/blog/resizing-images-with-php/
Displaying a 5109x3387 full colour image at 600x398 (or whatever it is)
is considered 'bad form' and obviously requires the image to be resized
each time NetSurf displays it onscreen. Perhaps NetSurf should be caching
the smaller version it creates for longer?
> I tried switching the Image options to "Use OS" and the image memory
> up to 100MB but it made no difference.
How long does it take for ChangeFSI to resize it to 600x398? About a
minute on this Iyonix. I don't think its entirely a NetSurf issue or a
memory size issue but a processor speed and an unfortunate web page
authoring issue. A side effect of a CMS no doubt.
Sunday, 16 June 2013
Slow image display
Visiting this page with NetSurf build #1257 on my Omega (300MHz
StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
It takes 66s to display, of which 45s is spent on the big image. And
this being RISC OS, that's 45s of non-multitasking :-(
NetSurf uses about 80MB of memory to display the image, then after the
page has been open for a minute, it releases most of that memory.
Great, except then if any of the window needs redrawing there is
another 45s wait :-(
Saving out the image, the OS can display it in only 1s, so why does
NetSurf take 40 times as long?
I tried switching the Image options to "Use OS" and the image memory
up to 100MB but it made no difference.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
StrongARM, RISC OS 4.39, 1920x1080x16m) is very slow:
http://stardot.org.uk/forums/viewtopic.php?f=16&t=6753
It takes 66s to display, of which 45s is spent on the big image. And
this being RISC OS, that's 45s of non-multitasking :-(
NetSurf uses about 80MB of memory to display the image, then after the
page has been open for a minute, it releases most of that memory.
Great, except then if any of the window needs redrawing there is
another 45s wait :-(
Saving out the image, the OS can display it in only 1s, so why does
NetSurf take 40 times as long?
I tried switching the Image options to "Use OS" and the image memory
up to 100MB but it made no difference.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
Saturday, 15 June 2013
New sourceforge bug form completely unusable
I am completely unable to add a comment to a bug report on
Sourceforge. When I post the comment I get error 302 followed by 404
if I click the link.
I wanted to reply to report 1453 - crash when closing window while
page is loading.
I'm getting this too. I clicked Adjust accidentally and closed the
resulting blank window. NetSurf crashed with a segmentation fault. I
can supply a log if necessary, except that I can't attach it to
someone else's bug report (and I can't do anything with the new
Sourceforge interface).
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Sourceforge. When I post the comment I get error 302 followed by 404
if I click the link.
I wanted to reply to report 1453 - crash when closing window while
page is loading.
I'm getting this too. I clicked Adjust accidentally and closed the
resulting blank window. NetSurf crashed with a segmentation fault. I
can supply a log if necessary, except that I can't attach it to
someone else's bug report (and I can't do anything with the new
Sourceforge interface).
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Friday, 14 June 2013
Re: streetmap.co.uk
On 14 Jun 2013 Rob Kendrick wrote:
> On Fri, Jun 14, 2013 at 09:58:17AM +0100, Richard Porter wrote:
>> On 13 Jun 2013 Bernard Boase wrote:
>>
>> NetSurf 2.9 will render the maps; the latest dev versions won't.
>> I've complained to streetmap about the removal of the old interface.
>> In particualr it makes it harder to extract the map images from a
>> saved draw file.
> Why do you think they care about removing the ability of their users to
> take copyrighted data they are not licenced to use, and for the sake of
> at most a few dozen users?
I don't, but it is perfectly reasonable to expect to be able to print
off a map for use away from the computer e.g. in the car or out
walking or cycling if you don't have a sat-nav. That is not an
infringement of copyright if it's for your own use and not republished
elsewhere. Anyway I didn't mention that to streetmap - only the fact
that the new interface doesn't work on any RISC OS browser. I
subsequently found that NS2.9 would still render the maps and possibly
other versions with JS off.
My point about extracting map images was inaccurate. In fact I just
delete all the extraneous stuff, leaving the actual map to be printed
on A4. I normally used Fresco because the saved draw files are
compatible with my printer whereas NetSurf's aren't due to 32-bit
colour sprites.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> On Fri, Jun 14, 2013 at 09:58:17AM +0100, Richard Porter wrote:
>> On 13 Jun 2013 Bernard Boase wrote:
>>
>> NetSurf 2.9 will render the maps; the latest dev versions won't.
>> I've complained to streetmap about the removal of the old interface.
>> In particualr it makes it harder to extract the map images from a
>> saved draw file.
> Why do you think they care about removing the ability of their users to
> take copyrighted data they are not licenced to use, and for the sake of
> at most a few dozen users?
I don't, but it is perfectly reasonable to expect to be able to print
off a map for use away from the computer e.g. in the car or out
walking or cycling if you don't have a sat-nav. That is not an
infringement of copyright if it's for your own use and not republished
elsewhere. Anyway I didn't mention that to streetmap - only the fact
that the new interface doesn't work on any RISC OS browser. I
subsequently found that NS2.9 would still render the maps and possibly
other versions with JS off.
My point about extracting map images was inaccurate. In fact I just
delete all the extraneous stuff, leaving the actual map to be printed
on A4. I normally used Fresco because the saved draw files are
compatible with my printer whereas NetSurf's aren't due to 32-bit
colour sprites.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: streetmap.co.uk
In message <000e0c75.01cce5000bbd@smtp.freeola.net>
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> It works if you enter a search location and then display the
> static map.
I'm using v1257.
After locating a significant map, I just put this url address into my
hotlist and now run SM from there.
--
BW Chris F.
If you buy energy from Npower and don't approve of Tax Avoidance go to
http://action.38degrees.org.uk/npower
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> It works if you enter a search location and then display the
> static map.
I'm using v1257.
After locating a significant map, I just put this url address into my
hotlist and now run SM from there.
--
BW Chris F.
If you buy energy from Npower and don't approve of Tax Avoidance go to
http://action.38degrees.org.uk/npower
Re: streetmap.co.uk
On Fri, Jun 14, 2013 at 09:58:17AM +0100, Richard Porter wrote:
> On 13 Jun 2013 Bernard Boase wrote:
>
> NetSurf 2.9 will render the maps; the latest dev versions won't.
> I've complained to streetmap about the removal of the old interface.
> In particualr it makes it harder to extract the map images from a
> saved draw file.
Why do you think they care about removing the ability of their users to
take copyrighted data they are not licenced to use, and for the sake of
at most a few dozen users?
What should happen here is that NetSurf gets developed more so the new
scheme works, and you should email somebody who gives a damn :)
B.
> On 13 Jun 2013 Bernard Boase wrote:
>
> NetSurf 2.9 will render the maps; the latest dev versions won't.
> I've complained to streetmap about the removal of the old interface.
> In particualr it makes it harder to extract the map images from a
> saved draw file.
Why do you think they care about removing the ability of their users to
take copyrighted data they are not licenced to use, and for the sake of
at most a few dozen users?
What should happen here is that NetSurf gets developed more so the new
scheme works, and you should email somebody who gives a damn :)
B.
Re: streetmap.co.uk
On 13 Jun 2013 Bernard Boase wrote:
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
> Any suggestions?
NetSurf 2.9 will render the maps; the latest dev versions won't.
I've complained to streetmap about the removal of the old interface.
In particualr it makes it harder to extract the map images from a
saved draw file.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
> Any suggestions?
NetSurf 2.9 will render the maps; the latest dev versions won't.
I've complained to streetmap about the removal of the old interface.
In particualr it makes it harder to extract the map images from a
saved draw file.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Thursday, 13 June 2013
Re: streetmap.co.uk
On 13 Jun, Alan Calder <alan_calder@o2.co.uk> wrote:
> Is 3.1 a JS enabled version and is the presence of such ability at the
> root of the problem?
You're right. If I disable Javascript (in Choices->Content) I do get
visible maps, now in the new theme and after a brief message advising
that Javascript, ..., er it disappears too quickly to read!
--
Bernard
> Is 3.1 a JS enabled version and is the presence of such ability at the
> root of the problem?
You're right. If I disable Javascript (in Choices->Content) I do get
visible maps, now in the new theme and after a brief message advising
that Javascript, ..., er it disappears too quickly to read!
--
Bernard
Re: streetmap.co.uk
> Date: Thu, 13 Jun 2013 10:22:43 +0100
> From: Bernard Boase <b.boase@bcs.org>
> Subject: streetmap.co.uk
> To: netsurf-users@netsurf-browser.org
> Message-ID: <026d155b53.boase@boase.demon.co.uk>
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
>
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
>
> Any suggestions?
>
I used Streetmap a few weeks ago and just tried again with the
1257 build.
It works if you enter a search location and then display the
static map.
Peter
> From: Bernard Boase <b.boase@bcs.org>
> Subject: streetmap.co.uk
> To: netsurf-users@netsurf-browser.org
> Message-ID: <026d155b53.boase@boase.demon.co.uk>
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
>
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
>
> Any suggestions?
>
I used Streetmap a few weeks ago and just tried again with the
1257 build.
It works if you enter a search location and then display the
static map.
Peter
Re: streetmap.co.uk
> But if javascript is on - then it does not work at all, doesn't display
> the "No javascript" message and doesn't progress (no change there
> either!)... Maybe this is your problem?
Hadn't explicitly thought about that, but I just (3.0) with JS enabled and
JS disabled. The behaviour seems to be the same. (But one thing I
reported before was incorrect. Changing scale keeps you in the old format.
It's just moving the centre that jumps to new format.)
Regards
--
John Harrison
Website http://jaharrison.me.uk
> the "No javascript" message and doesn't progress (no change there
> either!)... Maybe this is your problem?
Hadn't explicitly thought about that, but I just (3.0) with JS enabled and
JS disabled. The behaviour seems to be the same. (But one thing I
reported before was incorrect. Changing scale keeps you in the old format.
It's just moving the centre that jumps to new format.)
Regards
--
John Harrison
Website http://jaharrison.me.uk
Re: streetmap.co.uk
In article <535b3bc356john@jaharrison.me.uk>,
John Harrison <john@jaharrison.me.uk> wrote:
> > ... Streetmap hasn't changed recently...
> It has!
> I use it regularly and the behaviour changed (as per my previous posting)
> about a week ago.
Alright - I should have been more spoecific. There has been no change in
Streetmap's behaviour when used the way I outlined.
I've just updated to 3.1 (Dev CI #1257) and Streetmap (used the way I
said) behaves exactly as it always has.
But if javascript is on - then it does not work at all, doesn't display
the "No javascript" message and doesn't progress (no change there
either!)... Maybe this is your problem?
Support at Streetmap were very helpful: I contacted them some while ago,
when they changed to the new version, and was assured that the old version
would remain.
So whatever's happened is not a Netsurf thing...
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
John Harrison <john@jaharrison.me.uk> wrote:
> > ... Streetmap hasn't changed recently...
> It has!
> I use it regularly and the behaviour changed (as per my previous posting)
> about a week ago.
Alright - I should have been more spoecific. There has been no change in
Streetmap's behaviour when used the way I outlined.
I've just updated to 3.1 (Dev CI #1257) and Streetmap (used the way I
said) behaves exactly as it always has.
But if javascript is on - then it does not work at all, doesn't display
the "No javascript" message and doesn't progress (no change there
either!)... Maybe this is your problem?
Support at Streetmap were very helpful: I contacted them some while ago,
when they changed to the new version, and was assured that the old version
would remain.
So whatever's happened is not a Netsurf thing...
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Re: streetmap.co.uk
> ... Streetmap hasn't changed recently...
It has!
I use it regularly and the behaviour changed (as per my previous posting)
about a week ago.
Regards
--
John Harrison
Website http://jaharrison.me.uk
It has!
I use it regularly and the behaviour changed (as per my previous posting)
about a week ago.
Regards
--
John Harrison
Website http://jaharrison.me.uk
Re: streetmap.co.uk
In article <026d155b53.boase@boase.demon.co.uk>,
Bernard Boase <b.boase@bcs.org> wrote:
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
Seems to work OK, if you ignore the iffy formatting, in NS 2.9. I can
enter a postcode and get a map which I can then zoom in and out of and move
with the tools provided.
Is 3.1 a JS enabled version and is the presence of such ability at the root
of the problem?
Alan
--
Alan Calder, Milton Keynes, UK.
Bernard Boase <b.boase@bcs.org> wrote:
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
Seems to work OK, if you ignore the iffy formatting, in NS 2.9. I can
enter a postcode and get a map which I can then zoom in and out of and move
with the tools provided.
Is 3.1 a JS enabled version and is the presence of such ability at the root
of the problem?
Alan
--
Alan Calder, Milton Keynes, UK.
Re: streetmap.co.uk
In article <026d155b53.boase@boase.demon.co.uk>,
Bernard Boase <b.boase@bcs.org> wrote:
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
> Any suggestions?
I use Stretmap a lot.
But I always use it by clicking a link in StrongED. e.g.
http://streetmap.co.uk/loc/Burwell
This takes you to a page hich asks whih Burwell. Click the appropriate one.
Then you go to a page which asks for j/s. Wait and you do automatically to
the static map - which works absolutely fine.
This with 3.1 (Dev CI #1125)
Streetmap hasn't changed recently. You can also menu on a squatre of the
map and Object -> Object -> Save which can be dropped straight into
OpenVector and imported as a JPEG.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Bernard Boase <b.boase@bcs.org> wrote:
> Until recently Netsurf could render maps at streetmap.co.uk provided
> one entered via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
> drawfile could be extremely useful.
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
> Any suggestions?
I use Stretmap a lot.
But I always use it by clicking a link in StrongED. e.g.
http://streetmap.co.uk/loc/Burwell
This takes you to a page hich asks whih Burwell. Click the appropriate one.
Then you go to a page which asks for j/s. Wait and you do automatically to
the static map - which works absolutely fine.
This with 3.1 (Dev CI #1125)
Streetmap hasn't changed recently. You can also menu on a squatre of the
map and Object -> Object -> Save which can be dropped straight into
OpenVector and imported as a JPEG.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Re: streetmap.co.uk
> ... via their older interface at
> http://www.streetmap.co.uk/newdefaulte2.htm ... the map display is only
> in the new format which Netsurf apparently cannot display.
It has changed, and it is annoying, but what I get with NS 3.00 (and
RO5.18) is better than that.
It all works normally as far as displaying the first map. At that point I
used to edit the z= value in the URL to a small to a small even number (eg
2 or 4) which gave a much more useful 5x5 square display, but if I do that
now it jumps to the new format and tries to fit 25 map squares into the 3x3
window, making a right mess.
If I use any control (scale or move) it also jumps to the new format.
Most of the controls in the new format work OK, and there is one to switch
to 5x5, so you don't need to edit the URL.
The one thing that doesn't work is the search box. The Go button seems to
work, but I can't find a way to type into the search field.
I just tried it with Dev #953 (the latest I had loaded) and (a) it goes
straight to a new style page to offer you the alternative places, which
works but then (b) displays a blank map on which (c) none of the controls
work.
Regards
--
John Harrison
Website http://jaharrison.me.uk
> http://www.streetmap.co.uk/newdefaulte2.htm ... the map display is only
> in the new format which Netsurf apparently cannot display.
It has changed, and it is annoying, but what I get with NS 3.00 (and
RO5.18) is better than that.
It all works normally as far as displaying the first map. At that point I
used to edit the z= value in the URL to a small to a small even number (eg
2 or 4) which gave a much more useful 5x5 square display, but if I do that
now it jumps to the new format and tries to fit 25 map squares into the 3x3
window, making a right mess.
If I use any control (scale or move) it also jumps to the new format.
Most of the controls in the new format work OK, and there is one to switch
to 5x5, so you don't need to edit the URL.
The one thing that doesn't work is the search box. The Go button seems to
work, but I can't find a way to type into the search field.
I just tried it with Dev #953 (the latest I had loaded) and (a) it goes
straight to a new style page to offer you the alternative places, which
works but then (b) displays a blank map on which (c) none of the controls
work.
Regards
--
John Harrison
Website http://jaharrison.me.uk
Re: streetmap.co.uk
On 13 Jun 2013 as I do recall,
John Williams wrote:
> In article <026d155b53.boase@boase.demon.co.uk>,
> Bernard Boase <b.boase@bcs.org> wrote:
>
> > But now even entering via this URL, the map display is only in the new
> > format which Netsurf apparently cannot display. I am currently using
> > 3.1 (Dec Cl #1252).
>
> Seems to work OK with Dev CI #1257. Thanks for the URL - useful!
>
I got the Javascript error message, but then the page redirected to the
postcode I'd requested; and when I tried it again, I got the right page
straight away. So I'm not clear what is going on there...
http://www.streetmap.co.uk/oldmap.srf?x=345125&y=421641&z=0&sv=PR4+6AX&st=2&pc=PR4+6AX&mapp=oldmap.srf&searchp=oldsearch.srf
--
Harriet Bazley == Loyaulte me lie ==
Abstinence makes the heart grow fonder.
John Williams wrote:
> In article <026d155b53.boase@boase.demon.co.uk>,
> Bernard Boase <b.boase@bcs.org> wrote:
>
> > But now even entering via this URL, the map display is only in the new
> > format which Netsurf apparently cannot display. I am currently using
> > 3.1 (Dec Cl #1252).
>
> Seems to work OK with Dev CI #1257. Thanks for the URL - useful!
>
I got the Javascript error message, but then the page redirected to the
postcode I'd requested; and when I tried it again, I got the right page
straight away. So I'm not clear what is going on there...
http://www.streetmap.co.uk/oldmap.srf?x=345125&y=421641&z=0&sv=PR4+6AX&st=2&pc=PR4+6AX&mapp=oldmap.srf&searchp=oldsearch.srf
--
Harriet Bazley == Loyaulte me lie ==
Abstinence makes the heart grow fonder.
Re: streetmap.co.uk
In article <026d155b53.boase@boase.demon.co.uk>,
Bernard Boase <b.boase@bcs.org> wrote:
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
Seems to work OK with Dev CI #1257. Thanks for the URL - useful!
John
Bernard Boase <b.boase@bcs.org> wrote:
> But now even entering via this URL, the map display is only in the new
> format which Netsurf apparently cannot display. I am currently using
> 3.1 (Dec Cl #1252).
Seems to work OK with Dev CI #1257. Thanks for the URL - useful!
John
streetmap.co.uk
Until recently Netsurf could render maps at streetmap.co.uk provided
one entered via their older interface at
http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
drawfile could be extremely useful.
But now even entering via this URL, the map display is only in the new
format which Netsurf apparently cannot display. I am currently using
3.1 (Dec Cl #1252).
Any suggestions?
--
Bernard
one entered via their older interface at
http://www.streetmap.co.uk/newdefaulte2.htm from which exporting a
drawfile could be extremely useful.
But now even entering via this URL, the map display is only in the new
format which Netsurf apparently cannot display. I am currently using
3.1 (Dec Cl #1252).
Any suggestions?
--
Bernard
Tuesday, 11 June 2013
Re: [Patch] Add support for parsing writing-mode property v1
I just realized I've forgotten to attach the current version of the writing-mode property patch, so here :>
Re: [Patch] Add support for parsing writing-mode property v1
I still have not added any tests explicitly regarding the writing-mode property, however I have gotten everything to a stage where all tests are passing, which previously was not the case.
I could use some guidance writing parse/select tests for the property because even after studying the test programs and data files, it's not really obvious what the system is -- And beyond that, since I'm not really a CSS guru by any means, it is likely that I would write incorrect expectations when e.g. important is used.
It seems that there will also be a few more properties to add, including 'text-orientation' and 'direction', I'm not sure if I should add those as part of this patch or perhaps add those in subsequent chunks.
You're all busy people so when you have some time just give me a nod and I'll see what I can do.
On 2013-06-07, at 5:12 AM, John-Mark Bell <jmb@netsurf-browser.org> wrote:
> On Fri, 2013-06-07 at 04:09 -0400, Caitlin Potter wrote:
>> This patch is intended to support the parsing and storage of the
>> "writing-mode" property, which is one of the building blocks for
>> vertical text in css (support for which is currently required by the
>> HTML5 track element and obviously is a pretty important localization
>> feature -- and just simply looks cool, too).
>
> Excellent. Thanks for your work on this.
>
> [...]
>
>> It is quite likely that there are things substantially wrong,
>> including the lack of test data (I haven't figured out how to get the
>> test suite to even build and run yet, `make test` seems to fail
>> substantially here.)
>
> You're using a Mac, right? I've no current idea why make test isn't
> working for you on that platform, as the test infrastructure is pretty
> trivial. We're investigating that now.
>
>> So some review would be good, I'd like to get this approved by netsurf
>> devs before trying to squeeze it into mozilla-servo.
>
> In general, this looks fine to me (modulo the lack of test data, which
> you've mentioned above). There are a few minor whitespace nits, which
> can be fixed when we merge the change in. Additionally, there's a stray
> commented-out chunk in css__set_writing_mode_from_hint. This, too is
> trivially fixed, so I'm not concerned by it.
>
>
> J.
>
>
>
>
I could use some guidance writing parse/select tests for the property because even after studying the test programs and data files, it's not really obvious what the system is -- And beyond that, since I'm not really a CSS guru by any means, it is likely that I would write incorrect expectations when e.g. important is used.
It seems that there will also be a few more properties to add, including 'text-orientation' and 'direction', I'm not sure if I should add those as part of this patch or perhaps add those in subsequent chunks.
You're all busy people so when you have some time just give me a nod and I'll see what I can do.
On 2013-06-07, at 5:12 AM, John-Mark Bell <jmb@netsurf-browser.org> wrote:
> On Fri, 2013-06-07 at 04:09 -0400, Caitlin Potter wrote:
>> This patch is intended to support the parsing and storage of the
>> "writing-mode" property, which is one of the building blocks for
>> vertical text in css (support for which is currently required by the
>> HTML5 track element and obviously is a pretty important localization
>> feature -- and just simply looks cool, too).
>
> Excellent. Thanks for your work on this.
>
> [...]
>
>> It is quite likely that there are things substantially wrong,
>> including the lack of test data (I haven't figured out how to get the
>> test suite to even build and run yet, `make test` seems to fail
>> substantially here.)
>
> You're using a Mac, right? I've no current idea why make test isn't
> working for you on that platform, as the test infrastructure is pretty
> trivial. We're investigating that now.
>
>> So some review would be good, I'd like to get this approved by netsurf
>> devs before trying to squeeze it into mozilla-servo.
>
> In general, this looks fine to me (modulo the lack of test data, which
> you've mentioned above). There are a few minor whitespace nits, which
> can be fixed when we merge the change in. Additionally, there's a stray
> commented-out chunk in css__set_writing_mode_from_hint. This, too is
> trivially fixed, so I'm not concerned by it.
>
>
> J.
>
>
>
>
Sunday, 9 June 2013
Re: [Rpcemu] Networking: an interesting discovery (I think)
On 7 Jun 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
[snip]
> > Don't know if this has already been attempted, but how about saving
> > off the log file, rpclog.txt?, after each of these attempts so you
> > or others can see if their differences explain why? If not, it
> > suggests more logging is required in some areas to catch problems in
> > the field.
>
> I attach 2 log files [rpclog_089-402-OK and rpclog_089-402-Fail], made
> from successive attempts to launch 089/402, the first failing to
> network, the second attempt (after PC reboot) succeeding. The only
> difference I can see is the last line in #-Fail, 'Tap-Win32:
> tap_cleanup', which doesn't exist in the, otherwise identical,
> successful log. HTH,
Not having RO 4.02, I launched RPECmu0810/RO439 when the underlying
Windows system was 'busy', causing the network connection to fail, and,
after quitting RPCEmu, copied rpclog.txt elsewhere. I then launched
RPECmu0810/RO439 when Windows appeared to be less busy, resulting in a
successful network connection, and again copied rpclog.txt.
SideDiff shows that the two rpclog.txt files are _identical_, both
ending with the lines, which are the same as George's (apart from the
absence of the last line in rpclog_089-402-OK):
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{9E5E57C8-FE40-4391-BA42-4F7C3FBADDA6}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.9.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
Networking available
RPCEmu: Machine reset complete
Path is \\.\E:
Opening \\.\E:
HostFS: Registration request version 1 accepted
Tap-Win32: tap_cleanup
No error is reported, and rpclog.txt states that 'Networking available',
even when the connection has failed.
I then installed Reporter 2.67a, and set it to log the boot sequence. In
both cases, fail and ok, no errors were reported.
Having set Reporter to monitor the Desktop, it listed the error 'Timed
out while connecting' (when the connection failed), but didn't indicate
what led to it. The error also appears in RO syslogs Errors as:
***Error***
Title : Error
Task : Unknown task
Message : Timed out while connecting
All very puzzling. Can anyone suggest how to identify the culprit?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
[snip]
> > Don't know if this has already been attempted, but how about saving
> > off the log file, rpclog.txt?, after each of these attempts so you
> > or others can see if their differences explain why? If not, it
> > suggests more logging is required in some areas to catch problems in
> > the field.
>
> I attach 2 log files [rpclog_089-402-OK and rpclog_089-402-Fail], made
> from successive attempts to launch 089/402, the first failing to
> network, the second attempt (after PC reboot) succeeding. The only
> difference I can see is the last line in #-Fail, 'Tap-Win32:
> tap_cleanup', which doesn't exist in the, otherwise identical,
> successful log. HTH,
Not having RO 4.02, I launched RPECmu0810/RO439 when the underlying
Windows system was 'busy', causing the network connection to fail, and,
after quitting RPCEmu, copied rpclog.txt elsewhere. I then launched
RPECmu0810/RO439 when Windows appeared to be less busy, resulting in a
successful network connection, and again copied rpclog.txt.
SideDiff shows that the two rpclog.txt files are _identical_, both
ending with the lines, which are the same as George's (apart from the
absence of the last line in rpclog_089-402-OK):
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{9E5E57C8-FE40-4391-BA42-4F7C3FBADDA6}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.9.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
Networking available
RPCEmu: Machine reset complete
Path is \\.\E:
Opening \\.\E:
HostFS: Registration request version 1 accepted
Tap-Win32: tap_cleanup
No error is reported, and rpclog.txt states that 'Networking available',
even when the connection has failed.
I then installed Reporter 2.67a, and set it to log the boot sequence. In
both cases, fail and ok, no errors were reported.
Having set Reporter to monitor the Desktop, it listed the error 'Timed
out while connecting' (when the connection failed), but didn't indicate
what led to it. The error also appears in RO syslogs Errors as:
***Error***
Title : Error
Task : Unknown task
Message : Timed out while connecting
All very puzzling. Can anyone suggest how to identify the culprit?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 7 June 2013
Re: [Rpcemu] Networking: an interesting discovery (I think)
RPCEmu 0.8.9 [DYNAREC NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.6.1
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x300
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 3
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
loadconfig: bridgename = "rpcemu"
loadconfig: cpu_idle = "1"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "72"
loadconfig: cdrom_enabled = "1"
loadconfig: blit_optimisation = "0"
loadconfig: refresh_rate = "60"
loadconfig: stretch_mode = "0"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: cpu_type = "SA110"
loadconfig: mem_size = "256"
romload: Loaded 'ROM402' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{F8178C2D-0346-4469-A93A-BF05583FFF95}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.9.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
Networking available
RPCEmu: Machine reset complete
Path is \\.\E:
Opening \\.\E:
HostFS: Registration request version 1 accepted
RPCEmu 0.8.9 [DYNAREC NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.6.1
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x300
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 3
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
loadconfig: bridgename = "rpcemu"
loadconfig: cpu_idle = "1"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "72"
loadconfig: cdrom_enabled = "1"
loadconfig: blit_optimisation = "0"
loadconfig: refresh_rate = "60"
loadconfig: stretch_mode = "0"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: cpu_type = "SA110"
loadconfig: mem_size = "256"
romload: Loaded 'ROM402' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{F8178C2D-0346-4469-A93A-BF05583FFF95}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.9.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
Networking available
RPCEmu: Machine reset complete
Path is \\.\E:
Opening \\.\E:
HostFS: Registration request version 1 accepted
Tap-Win32: tap_cleanupIn message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
> Hi George,
[snip]
>
> Don't know if this has already been attempted, but how about saving off
> the log file, rpclog.txt?, after each of these attempts so you or others
> can see if their differences explain why? If not, it suggests more
> logging is required in some areas to catch problems in the field.
>
> Cheers, Ralph.
I attach 2 log files [rpclog_089-402-OK and rpclog_089-402-Fail], made
from successive attempts to launch 089/402, the first failing to
network, the second attempt (after PC reboot) succeeding. The only
difference I can see is the last line in #-Fail, 'Tap-Win32:
tap_cleanup', which doesn't exist in the, otherwise identical,
successful log. HTH,
George
--
george greenfield
Build: 32-bit binary
Compiler: GCC version 4.6.1
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x300
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 3
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
loadconfig: bridgename = "rpcemu"
loadconfig: cpu_idle = "1"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "72"
loadconfig: cdrom_enabled = "1"
loadconfig: blit_optimisation = "0"
loadconfig: refresh_rate = "60"
loadconfig: stretch_mode = "0"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: cpu_type = "SA110"
loadconfig: mem_size = "256"
romload: Loaded 'ROM402' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{F8178C2D-0346-4469-A93A-BF05583FFF95}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.9.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
Networking available
RPCEmu: Machine reset complete
Path is \\.\E:
Opening \\.\E:
HostFS: Registration request version 1 accepted
RPCEmu 0.8.9 [DYNAREC NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.6.1
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x300
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 3
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
loadconfig: bridgename = "rpcemu"
loadconfig: cpu_idle = "1"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "72"
loadconfig: cdrom_enabled = "1"
loadconfig: blit_optimisation = "0"
loadconfig: refresh_rate = "60"
loadconfig: stretch_mode = "0"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: cpu_type = "SA110"
loadconfig: mem_size = "256"
romload: Loaded 'ROM402' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{F8178C2D-0346-4469-A93A-BF05583FFF95}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.9.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
Networking available
RPCEmu: Machine reset complete
Path is \\.\E:
Opening \\.\E:
HostFS: Registration request version 1 accepted
Tap-Win32: tap_cleanupIn message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
> Hi George,
[snip]
>
> Don't know if this has already been attempted, but how about saving off
> the log file, rpclog.txt?, after each of these attempts so you or others
> can see if their differences explain why? If not, it suggests more
> logging is required in some areas to catch problems in the field.
>
> Cheers, Ralph.
I attach 2 log files [rpclog_089-402-OK and rpclog_089-402-Fail], made
from successive attempts to launch 089/402, the first failing to
network, the second attempt (after PC reboot) succeeding. The only
difference I can see is the last line in #-Fail, 'Tap-Win32:
tap_cleanup', which doesn't exist in the, otherwise identical,
successful log. HTH,
George
--
george greenfield
Re: value of length in css properties
In article
<OFC4CFBE13.FF734988-ONC1257B83.004C479D-C1257B83.004C479F@solog.net>,
<Valentin.Coudert@solog.net> wrote:
> When I retrieve some css properties, the value of length is not exactly
> equal to the value in my css file. For instance, I set 300% for the
> letter-spacing in my css file but the returned value is 307200. Is that
> normal ?
For letter spacing I'd expect percentage values to be rejected as
invalid. Also, note that values will be in css_fixed format. You can use
libcss/fpmath.h to convert. e.g. FIXTOINT or FIXTOFLT.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OFC4CFBE13.FF734988-ONC1257B83.004C479D-C1257B83.004C479F@solog.net>,
<Valentin.Coudert@solog.net> wrote:
> When I retrieve some css properties, the value of length is not exactly
> equal to the value in my css file. For instance, I set 300% for the
> letter-spacing in my css file but the returned value is 307200. Is that
> normal ?
For letter spacing I'd expect percentage values to be rejected as
invalid. Also, note that values will be in css_fixed format. You can use
libcss/fpmath.h to convert. e.g. FIXTOINT or FIXTOFLT.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
value of length in css properties
Hello,
When I retrieve some css properties, the value of length is not exactly equal to the value in my css file.
For instance, I set 300% for the letter-spacing in my css file but the returned value is 307200.
Is that normal ?
thanks
Valentin Coudert
Re: [Patch] Add support for parsing writing-mode property v1
On Fri, 2013-06-07 at 04:09 -0400, Caitlin Potter wrote:
> This patch is intended to support the parsing and storage of the
> "writing-mode" property, which is one of the building blocks for
> vertical text in css (support for which is currently required by the
> HTML5 track element and obviously is a pretty important localization
> feature -- and just simply looks cool, too).
Excellent. Thanks for your work on this.
[...]
> It is quite likely that there are things substantially wrong,
> including the lack of test data (I haven't figured out how to get the
> test suite to even build and run yet, `make test` seems to fail
> substantially here.)
You're using a Mac, right? I've no current idea why make test isn't
working for you on that platform, as the test infrastructure is pretty
trivial. We're investigating that now.
> So some review would be good, I'd like to get this approved by netsurf
> devs before trying to squeeze it into mozilla-servo.
In general, this looks fine to me (modulo the lack of test data, which
you've mentioned above). There are a few minor whitespace nits, which
can be fixed when we merge the change in. Additionally, there's a stray
commented-out chunk in css__set_writing_mode_from_hint. This, too is
trivially fixed, so I'm not concerned by it.
J.
> This patch is intended to support the parsing and storage of the
> "writing-mode" property, which is one of the building blocks for
> vertical text in css (support for which is currently required by the
> HTML5 track element and obviously is a pretty important localization
> feature -- and just simply looks cool, too).
Excellent. Thanks for your work on this.
[...]
> It is quite likely that there are things substantially wrong,
> including the lack of test data (I haven't figured out how to get the
> test suite to even build and run yet, `make test` seems to fail
> substantially here.)
You're using a Mac, right? I've no current idea why make test isn't
working for you on that platform, as the test infrastructure is pretty
trivial. We're investigating that now.
> So some review would be good, I'd like to get this approved by netsurf
> devs before trying to squeeze it into mozilla-servo.
In general, this looks fine to me (modulo the lack of test data, which
you've mentioned above). There are a few minor whitespace nits, which
can be fixed when we merge the change in. Additionally, there's a stray
commented-out chunk in css__set_writing_mode_from_hint. This, too is
trivially fixed, so I'm not concerned by it.
J.
[Patch] Add support for parsing writing-mode property v1
This patch is intended to support the parsing and storage of the "writing-mode" property, which is one of the building blocks for vertical text in css (support for which is currently required by the HTML5 track element and obviously is a pretty important localization feature -- and just simply looks cool, too).
The layout side of things can be dealt with elsewhere, but first and foremost is getting libcss to support the property.
A link to the current draft is here http://dev.w3.org/csswg/css-writing-modes/ with the writing-mode property in particular described in http://dev.w3.org/csswg/css-writing-modes/#writing-mode
===
So some review would be good, I'd like to get this approved by netsurf devs before trying to squeeze it into mozilla-servo.
Any and all feedback is much appreciated, thanks a bunch.
Thursday, 6 June 2013
Re: Visited links
On 6 Jun 2013 Rob Kendrick wrote:
> On Thu, Jun 06, 2013 at 11:03:25AM +0100, Richard Porter wrote:
>> I've noticed that since quite recently NS has been preserving visited
>> link status over several sessions instead of starting from scratch
>> each time.
> This has always been the case. A link is "visited" if it is in the
> history (or rather, in the urldb with a non-zero "visited" count.)
> The only recent change is that we re-enabled the code to colour links
> differently if they had a non-zero visited count.
Thanks, that explains why I have just noticed it.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> On Thu, Jun 06, 2013 at 11:03:25AM +0100, Richard Porter wrote:
>> I've noticed that since quite recently NS has been preserving visited
>> link status over several sessions instead of starting from scratch
>> each time.
> This has always been the case. A link is "visited" if it is in the
> history (or rather, in the urldb with a non-zero "visited" count.)
> The only recent change is that we re-enabled the code to colour links
> differently if they had a non-zero visited count.
Thanks, that explains why I have just noticed it.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: Visited links
On Thu, Jun 06, 2013 at 11:03:25AM +0100, Richard Porter wrote:
> I've noticed that since quite recently NS has been preserving visited
> link status over several sessions instead of starting from scratch
> each time.
This has always been the case. A link is "visited" if it is in the
history (or rather, in the urldb with a non-zero "visited" count.)
The only recent change is that we re-enabled the code to colour links
differently if they had a non-zero visited count.
B.
> I've noticed that since quite recently NS has been preserving visited
> link status over several sessions instead of starting from scratch
> each time.
This has always been the case. A link is "visited" if it is in the
history (or rather, in the urldb with a non-zero "visited" count.)
The only recent change is that we re-enabled the code to colour links
differently if they had a non-zero visited count.
B.
Visited links
I've noticed that since quite recently NS has been preserving visited
link status over several sessions instead of starting from scratch
each time. Is this related to the site history duration in the
Security choices?
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
link status over several sessions instead of starting from scratch
each time. Is this related to the site history duration in the
Security choices?
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Tuesday, 4 June 2013
Re: [Rpcemu] Networking: an interesting discovery (I think)
In message <0208af5653.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 4 Jun 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>> In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
[snip]
>
> C:\Program Files\RPCEmu\rpclog.txt is written automatically every time
> RPCEmu 0.8.10 starts.
>
> There won't be a copy in the distribution zipfile, because RPCEmu has
> not been run, whilst still in the archive.
>
> Tony
Thanks, Tony: live and learn!
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 4 Jun 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>> In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
[snip]
>
> C:\Program Files\RPCEmu\rpclog.txt is written automatically every time
> RPCEmu 0.8.10 starts.
>
> There won't be a copy in the distribution zipfile, because RPCEmu has
> not been run, whilst still in the archive.
>
> Tony
Thanks, Tony: live and learn!
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Networking: an interesting discovery (I think)
On 4 Jun 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
[snip]
> > Don't know if this has already been attempted, but how about saving
> > off the log file, rpclog.txt?, after each of these attempts so you
> > or others can see if their differences explain why? If not, it
> > suggests more logging is required in some areas to catch problems in
> > the field.
>
> I would do, but there was no rpclog.txt file in my Zip of 0.8.10 (see
> attached screenshot - forwarded to Ralph separately). My 0.8.9
> installation does have one, so I'll save it next time I hit problems.
> It would be handy for 0.8.10 as well...
C:\Program Files\RPCEmu\rpclog.txt is written automatically every time
RPCEmu 0.8.10 starts.
There won't be a copy in the distribution zipfile, because RPCEmu has
not been run, whilst still in the archive.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
[snip]
> > Don't know if this has already been attempted, but how about saving
> > off the log file, rpclog.txt?, after each of these attempts so you
> > or others can see if their differences explain why? If not, it
> > suggests more logging is required in some areas to catch problems in
> > the field.
>
> I would do, but there was no rpclog.txt file in my Zip of 0.8.10 (see
> attached screenshot - forwarded to Ralph separately). My 0.8.9
> installation does have one, so I'll save it next time I hit problems.
> It would be handy for 0.8.10 as well...
C:\Program Files\RPCEmu\rpclog.txt is written automatically every time
RPCEmu 0.8.10 starts.
There won't be a copy in the distribution zipfile, because RPCEmu has
not been run, whilst still in the archive.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Networking: an interesting discovery (I think)
In message <20130604155952.6078224C4A@orac.inputplus.co.uk> you wrote:
> Hi George,
>
>> Then, after waiting for the PC harddrive to calm down, launching
>> RPCEmu with networking enabled results in a connection, if not on the
>> first, then usually on the second and invariably on the third,
>> relaunch.
>
> Don't know if this has already been attempted, but how about saving off
> the log file, rpclog.txt?, after each of these attempts so you or others
> can see if their differences explain why? If not, it suggests more
> logging is required in some areas to catch problems in the field.
>
> Cheers, Ralph.
I would do, but there was no rpclog.txt file in my Zip of 0.8.10 (see
attached screenshot - forwarded to Ralph separately). My 0.8.9
installation does have one, so I'll save it next time I hit problems.
It would be handy for 0.8.10 as well...
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hi George,
>
>> Then, after waiting for the PC harddrive to calm down, launching
>> RPCEmu with networking enabled results in a connection, if not on the
>> first, then usually on the second and invariably on the third,
>> relaunch.
>
> Don't know if this has already been attempted, but how about saving off
> the log file, rpclog.txt?, after each of these attempts so you or others
> can see if their differences explain why? If not, it suggests more
> logging is required in some areas to catch problems in the field.
>
> Cheers, Ralph.
I would do, but there was no rpclog.txt file in my Zip of 0.8.10 (see
attached screenshot - forwarded to Ralph separately). My 0.8.9
installation does have one, so I'll save it next time I hit problems.
It would be handy for 0.8.10 as well...
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Networking: an interesting discovery (I think)
Hi George,
> Then, after waiting for the PC harddrive to calm down, launching
> RPCEmu with networking enabled results in a connection, if not on the
> first, then usually on the second and invariably on the third,
> relaunch.
Don't know if this has already been attempted, but how about saving off
the log file, rpclog.txt?, after each of these attempts so you or others
can see if their differences explain why? If not, it suggests more
logging is required in some areas to catch problems in the field.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Then, after waiting for the PC harddrive to calm down, launching
> RPCEmu with networking enabled results in a connection, if not on the
> first, then usually on the second and invariably on the third,
> relaunch.
Don't know if this has already been attempted, but how about saving off
the log file, rpclog.txt?, after each of these attempts so you or others
can see if their differences explain why? If not, it suggests more
logging is required in some areas to catch problems in the field.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: description of css_select_handler functions
In article
<OFBC71A18E.7E474887-ONC1257B80.00401579-C1257B80.0040157A@solog.net>,
<Valentin.Coudert@solog.net> wrote:
> I would like to use LibCSS but for some functions of the
> css_select_handler structure (libcss/select.h), I don't understand what
> they are supposed to do (and to return). Is there any documentation
> somewhere ?
You could have a look at the implementations in NetSurf.
See css/select.c:
http://source.netsurf-browser.org/netsurf.git/tree/css/select.c
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OFBC71A18E.7E474887-ONC1257B80.00401579-C1257B80.0040157A@solog.net>,
<Valentin.Coudert@solog.net> wrote:
> I would like to use LibCSS but for some functions of the
> css_select_handler structure (libcss/select.h), I don't understand what
> they are supposed to do (and to return). Is there any documentation
> somewhere ?
You could have a look at the implementations in NetSurf.
See css/select.c:
http://source.netsurf-browser.org/netsurf.git/tree/css/select.c
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
description of css_select_handler functions
Hello,
I would like to use LibCSS but for some functions of the css_select_handler structure (libcss/select.h), I don't understand what they are supposed to do (and to return).
Is there any documentation somewhere ?
thanks
V. Coudert
Monday, 3 June 2013
[Rpcemu] Networking: an interesting discovery (I think)
Having now got networking running reliably on 0.8.10/5.19 (and having
practically gone potty in the process), it seems to be the case, on my
system at least*, that where network-enabled RPCEmu fails to connect
with the network bridge on repeated restarts, the best solution is to
reboot the PC.
Then, after waiting for the PC harddrive to calm down, launching
RPCEmu with networking enabled results in a connection, if not on the
first, then usually on the second and invariably on the third,
relaunch.
No other procedure has been consistently successful, neither
re-entering RISC OS's Configure-Network-Internet settings between
startups, nor using RPCEmu's File-Reset to shut down, nor reselecting
RPCEmu's Settings-Networking-Internet Bridging between startups, nor
enabling/disabling Reduce CPU Usage. But PC rebooting has for several
days now invariably done the trick. And no, I don't know why/how!
George
*Win7/64 PC, Dell XPS Desktop, 4MB RAM, Intel Core i7 quad-core.
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
practically gone potty in the process), it seems to be the case, on my
system at least*, that where network-enabled RPCEmu fails to connect
with the network bridge on repeated restarts, the best solution is to
reboot the PC.
Then, after waiting for the PC harddrive to calm down, launching
RPCEmu with networking enabled results in a connection, if not on the
first, then usually on the second and invariably on the third,
relaunch.
No other procedure has been consistently successful, neither
re-entering RISC OS's Configure-Network-Internet settings between
startups, nor using RPCEmu's File-Reset to shut down, nor reselecting
RPCEmu's Settings-Networking-Internet Bridging between startups, nor
enabling/disabling Reduce CPU Usage. But PC rebooting has for several
days now invariably done the trick. And no, I don't know why/how!
George
*Win7/64 PC, Dell XPS Desktop, 4MB RAM, Intel Core i7 quad-core.
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 1 June 2013
Re: Options/Choices refactor
On 31 May 2013 23:11:27 +0100, Chris Young wrote:
> I did try running the colour_option_from_pen functions through with
> nsoptions_default parameter, but about:config shows the system colours
> options are then "user" settings (for some reason). That's no good as
> they get written back to Choices, which puts us back to square 1.
Ah, I see why - the user option needs updating manually if it is the
same as the default. I've fixed it (and added some macros to do this
for non-string values).
The treeviews seem to create themselves using old colours though.
Maybe it was always like that and I didn't notice.
Chris
> I did try running the colour_option_from_pen functions through with
> nsoptions_default parameter, but about:config shows the system colours
> options are then "user" settings (for some reason). That's no good as
> they get written back to Choices, which puts us back to square 1.
Ah, I see why - the user option needs updating manually if it is the
same as the default. I've fixed it (and added some macros to do this
for non-string values).
The treeviews seem to create themselves using old colours though.
Maybe it was always like that and I didn't notice.
Chris
Re: Colours
I have deleted my choices file, let Netsurf re-create is and then added in a few
missing items:
Is this grey on black text a result of the colour changes ?
http://www.telegraph.co.uk/news/worldnews/g8/10091729/Fake-shops-open-up-ahead-of-the-G8-summit.html
ca_bundle:./res/cabundle
ca_path:./res/certs
font_size:144
accept_language:en
memory_cache_size:20000030
homepage_url:/g/Applications/netsurf/hotlist.htm
core_select_menu:1
atari_transparency:16777217
atari_editor:/g/Applications/netsurf/everest.prg
downloads_path:./download
url_file:./res/url.db
hotlist_file:./res/hotlist
tree_icons_path:./res/icons
Regards,
Peter
missing items:
Is this grey on black text a result of the colour changes ?
http://www.telegraph.co.uk/news/worldnews/g8/10091729/Fake-shops-open-up-ahead-of-the-G8-summit.html
ca_bundle:./res/cabundle
ca_path:./res/certs
font_size:144
accept_language:en
memory_cache_size:20000030
homepage_url:/g/Applications/netsurf/hotlist.htm
core_select_menu:1
atari_transparency:16777217
atari_editor:/g/Applications/netsurf/everest.prg
downloads_path:./download
url_file:./res/url.db
hotlist_file:./res/hotlist
tree_icons_path:./res/icons
Regards,
Peter
Subscribe to:
Posts (Atom)