Re: Treeview triangles

On Mon, 30 Sep 2013 20:03:20 +0100, Michael Drake wrote:

> We'll need to sort
> out how we're going to do this stuff properly when it comes time to
> implement HTML5 Canvas. One idea we've had is to use libnsfb to draw
> canvas bitmaps, but anti-aliasing needs added to libnsfb.

I don't see why Canvas would need anything other than the usual
plotters - it's only a dedicated area which is drawn into, isn't it?
Effectively it's the same as an IFrame.

Chris

Re: Treeview triangles

Am Montag, den 30.09.2013, 21:03 +0200 schrieb Michael Drake
<tlsa@netsurf-browser.org>:


> I think a polygon plot is the best solution for now.

I agree with that option.
The problem also appears with the atari frontend, but it's not really
atari
or FreeMiNT related. It's about the font used for treeview redraws.
I do pack the netsurf package with the Bitsream Vera font, because
it is small compared to the Deja-Vu font (several MB smaller).
Also, I bet the internal font renderer for the framebuffer frontend
probably has no triangles.
Also, I don't like the idea that the treeview is dependent on the font
plotter / the font.


> We'll need to sort
> out how we're going to do this stuff properly when it comes time to
> implement HTML5 Canvas. One idea we've had is to use libnsfb to draw
> canvas bitmaps, but anti-aliasing needs added to libnsfb.

Anti-aliasing is so important for the treeview? I doubt that.
KISS! I vote for the polygon plot! :)

Greets,
Ole

Re: Treeview triangles

On Mon, 30 Sep 2013 19:51:43 +0100, Michael Drake wrote:

> How did the triangles on my test page look on the Amiga?

They look OK: http://homepage.ntlworld.com/cdyoung/tmp/triangles.png
And that's using the default plotters with no anti-aliasing.

Chris

Re: Treeview triangles

On Mon, 30 Sep 2013 16:55:51 +0100, Rob Kendrick wrote:

> On Mon, Sep 30, 2013 at 04:32:43PM +0100, Michael Drake wrote:
> >
> > When the triangle glyphs aren't available (as is the case on certain
> > platforms, unless we distribute the glyphs ourselves), the treeviews don't
> > look satisfactory.
> >
> > As an alternative, I could just draw triangles with the polygon plotter.
> >
> > There are a few drawbacks with this:
> >
> > - Triangle has to have dimensions which are even or the
> > triangle will look lopsided.
> > - Polygon plotter may not anti-alias.

Can we ask the frontend if it has the glyphs available, or is that
unnecessary complication?

Is it just RISC OS with the problem, as you seem to be suggesting
other platforms are missing these glyphs too?

> Alternatively, we implement a generic anti-aliased plotter for other
> front ends to use.

Whilst I'd like a core anti-aliased plotter, I'm not sure how that
would work, and it sounds like an awful lot of work.

For this specific triangle problem, I can see that plotting them
anti-aliased into a bitmap, and then getting the frontend to plot the
bitmap might work, if a reasonable anti-aliased triangle plotting
routine can be written.

Chris

Re: Treeview triangles

In article <53936ba29ftlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:

> I'm not sure. It's trivial to make the core call a frontend-implemented
> nsfont_glyph_exists, or some such, but I'm not sure how easy it is to
> implement on all platforms. Also, I don't like increasing the amount of
> stuff a frontend needs to implement.

I don't like this idea because if front ends can detect non-existence of
glyphs, they could be doing some transliteration. In this case, replacing
the gylphs with "V" and ">".

I think a polygon plot is the best solution for now. We'll need to sort
out how we're going to do this stuff properly when it comes time to
implement HTML5 Canvas. One idea we've had is to use libnsfb to draw
canvas bitmaps, but anti-aliasing needs added to libnsfb.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Treeview triangles

In article
<OUT-5249CDDE.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:

> Can we ask the frontend if it has the glyphs available, or is that
> unnecessary complication?

I'm not sure. It's trivial to make the core call a frontend-implemented
nsfont_glyph_exists, or some such, but I'm not sure how easy it is to
implement on all platforms. Also, I don't like increasing the amount of
stuff a frontend needs to implement.

> Is it just RISC OS with the problem, as you seem to be suggesting
> other platforms are missing these glyphs too?

Same problem on Atari, apparently. When we get round to adding treeviews
to the framebuffer frontend, it will have the same issue too.

> Whilst I'd like a core anti-aliased plotter, I'm not sure how that
> would work, and it sounds like an awful lot of work.

How did the triangles on my test page look on the Amiga?

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Treeview triangles

In article <20130930155550.GK26731@pepperfish.net>,
Rob Kendrick <rjek@netsurf-browser.org> wrote:

> Ship PNG images, and plot them instead? I suppose that won't react to
> colour theme.

Yes, or size.

> Alternatively, we implement a generic anti-aliased plotter for other
> front ends to use.

I thought of bitmap generation, and plot via bitmap plotter. But at that
point, it's rather more complexity than its worth.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Treeview triangles

On Mon, Sep 30, 2013 at 04:32:43PM +0100, Michael Drake wrote:
>
> When the triangle glyphs aren't available (as is the case on certain
> platforms, unless we distribute the glyphs ourselves), the treeviews don't
> look satisfactory.
>
> As an alternative, I could just draw triangles with the polygon plotter.
>
> There are a few drawbacks with this:
>
> - Triangle has to have dimensions which are even or the
> triangle will look lopsided.
> - Polygon plotter may not anti-alias.

Ship PNG images, and plot them instead? I suppose that won't react to
colour theme.

Alternatively, we implement a generic anti-aliased plotter for other
front ends to use.

B.

Treeview triangles

When the triangle glyphs aren't available (as is the case on certain
platforms, unless we distribute the glyphs ourselves), the treeviews don't
look satisfactory.

As an alternative, I could just draw triangles with the polygon plotter.

There are a few drawbacks with this:

- Triangle has to have dimensions which are even or the
triangle will look lopsided.
- Polygon plotter may not anti-alias.

You can see how they would look on this page, where I've faked them up
with borders that NetSurf plots via the polygon plotter:

http://www.netsurf-browser.org/temp/treeview/triangles.html

Any thoughts?

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Hotlist editing

On 29 Sep 2013 as I do recall,
Michael Drake wrote:

> In article <6f29e49253.harriet@blueyonder.co.uk>,
> Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
>
> > It is (as of at least v1356, and currently in v1359) no longer possible
> > to edit/manually update the URLs in a hotlist, something which I used do
> > on a regular basis.
>
> Alt+Click? It should behave like the filer.
>
Ah, that works, yes. :-)

It's just the actual visible 'Edit' function on the menu that has
changed, then.

--
Harriet Bazley == Loyaulte me lie ==

We are not punished for our sins, but by them.

Re: Hotlist editing

In article <6f29e49253.harriet@blueyonder.co.uk>,
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:

> It is (as of at least v1356, and currently in v1359) no longer possible
> to edit/manually update the URLs in a hotlist, something which I used do
> on a regular basis.

Alt+Click? It should behave like the filer.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Hotlist editing

It is (as of at least v1356, and currently in v1359) no longer possible
to edit/manually update the URLs in a hotlist, something which I used do
on a regular basis. The Selection->Edit menu entry now provides an
editable field for only the hotlist entry's title.

(Also, if you select an entry for editing when the existing page title
is wider than the currently displayed extent of the window and then
resize the window to allow you to read the right-hand end of it, the
newly-displayed inverted section of the display doesn't update
correctly. And you can't scroll to the right to view the right-hand
end of such long titles without resizing the window, because the
horizontal scroll bar/arrows on the hotlist window don't work.)

For example, I have a hotlist entry which reads
A Study in Magic: The Perils of Deduction, a Harry Potter + Sherlock
Crossover fanfic Chapter 32
http://m.fanfiction.net/s/7578572/32/A-Study-in-Magic

The fiction in question has 66 chapters, and I previously read one at a
time and updated the URL (and, if I remembered, the chapter number at
the end of the hotlist entry title) to point to the next chapter.

Obviously, the title doesn't *need* to be that long - it was simply the
automatic default - and I could edit it down to make it a similar length
to the other entries in the hotlist like "Netsurf test builds", in order
to sidestep the redraw bug. (I do have others from the same site even
longer....)

However, not being able to update URLs once read is having a
considerable impact on my bookmarking habits. Is this loss of
functionality intentional, or is it an accidental side-effect of the
display changes?

--
Harriet Bazley == Loyaulte me lie ==

People who live in stone houses shouldn't throw glasses.

Re: [Rpcemu] Filetype translation

On 19 Sep 2013, at 23:28, Peter Howkins wrote:

find . -depth -type f -name "*.txt" -exec sh -c 'mv "$1" "${1%.txt},fff"' _ {} \;
find . -depth -type f -name "*.dat" -exec sh -c 'mv "$1" "${1%.dat},ffd"' _ {} \;
find . -depth -type f -name "*.htm" -exec sh -c 'mv "$1" "${1%.htm},faf"' _ {} \;
find . -depth -type f -name "*.arc" -exec sh -c 'mv "$1" "${1%.arc},ddc"' _ {} \;
find . -depth -type f -name "*.png" -exec sh -c 'mv "$1" "${1%.png},b60"' _ {} \;

find . -depth -type f -name "*.jpg" -exec sh -c 'mv "$1" "${1%.jpg},c85"' _ {} \; && \
find . -depth -type f -name "*.jpeg" -exec sh -c 'mv "$1" "${1%.jpeg},c85"' _ {} \; && \
find . -depth -type f -name "*.gif" -exec sh -c 'mv "$1" "${1%.gif},695"' _ {} \; && \
find . -depth -type f -name "*.html" -exec sh -c 'mv "$1" "${1%.html},faf"' _ {} \;

Cheers Peter.

Now worked out how to put this into a Unix batch file and run it under Mac OS. I added in

find . -depth -type f -name "*.oby" -exec sh -c 'mv "$1" "${1%.oby},feb"' _ {} \;

plus put a command at the start to change directory

cd /users/gerald/dropbox/emulation/redsquirrel_disk439

so I didn't screw the entire drive. I then saved the file as a text file (convert.txt) and typed

sh convert.txt

Now to see if it'll load into RPCemu...

Re: Automatic backend selection in nsfb

I just wanted to follow up on this before I start making any changes.
It looks like the appropriate place to implement auto-backend select is:

src/libnsfb.c

nsfb_t*
nsfb_new(const enum nsfb_type_e surface_type)
{
nsfb_t *newfb;
newfb = calloc(1, sizeof(nsfb_t));
if (newfb == NULL)
- return NULL;
+{
+ /*autoselect code here: if (getenv("WAYLAND_DISPLAY")) ... */
+}else{

It looks like modes that are not supported still get checked,
but could be skipped if libnsfb.h had some #ifdefs for:

enum nsfb_type_e {
NSFB_SURFACE_NONE = 0, /**< No surface */
NSFB_SURFACE_RAM, /**< RAM surface */
#ifdef NSFB_SDL_AVAILABLE
NSFB_SURFACE_SDL, /**< SDL surface */

Re: [Rpcemu] Filetype translation

On Sat, Sep 14, 2013 at 09:36:53AM +0100, Gerald Holdsworth wrote:
> Hi all,
> Is there a way to specify the translation of Windows/Mac files to RISC OS
> filetypes in RPCemu?

No, mainly as things end up as broken as the red squirrel tree you mention
below.

> I have a RISC OS 4.39 HostFS disc image from RedSquirrel, with tons of
> applications in it, and want to open these in RPCemu...but one can't just
> drag the entire disc image into an RPCemu HostFS directory, as both treat
> filetypes differently. At the moment, my only solution would be to try and
> fire up RedSquirrel and ZIP each and every application (or folders of
> them), then bring these across to RPCemu. However, if there is someway of
> telling RPCemu that an '.oby' file is a RISC OS Obey file, for example, it
> would make life so much easier...IIRC, RS has all these definitions in a
> text lookup file.

Restoring a red squirrel tree for use in rpcemu involves renaming the
files, I have used cygwin (for a unix like bash shell under windows) and
the following commands to change all the filenames within the hostfs
tree. (note, don't run this on your whole harddisc, else a windows
reinstall would probably be needed ...)

find . -depth -type f -name "*.txt" -exec sh -c 'mv "$1" "${1%.txt},fff"' _ {} \;
find . -depth -type f -name "*.dat" -exec sh -c 'mv "$1" "${1%.dat},ffd"' _ {} \;
find . -depth -type f -name "*.htm" -exec sh -c 'mv "$1" "${1%.htm},faf"' _ {} \;
find . -depth -type f -name "*.arc" -exec sh -c 'mv "$1" "${1%.arc},ddc"' _ {} \;
find . -depth -type f -name "*.png" -exec sh -c 'mv "$1" "${1%.png},b60"' _ {} \;

find . -depth -type f -name "*.jpg" -exec sh -c 'mv "$1" "${1%.jpg},c85"' _ {} \; && \
find . -depth -type f -name "*.jpeg" -exec sh -c 'mv "$1" "${1%.jpeg},c85"' _ {} \; && \
find . -depth -type f -name "*.gif" -exec sh -c 'mv "$1" "${1%.gif},695"' _ {} \; && \
find . -depth -type f -name "*.html" -exec sh -c 'mv "$1" "${1%.html},faf"' _ {} \;

Peter

--
Peter Howkins
peter.howkins@marutan.net

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Changes to the RISC OS GUI in #1342

The following bytes were arranged on 14 Sep 2013 by Bernard Boase :

> Bugs reported in February 2013 (and earlier) seem to suggest that work
> has been done on making <textarea> handling more robust. So is my
> problem a known one, or one that is related to your mouse tracking
> code, or is it just my system experiencing some problem in keeping the
> window fully refreshed?

Hmm...

> Geminus

There's yer problem.

Tried disabling Geminus for NetSurf?

--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================

Re: [Rpcemu] Filetype translation

On 15 Sep 2013, Gerald Holdsworth <gerald@hollypops.co.uk> wrote:
> On 15 Sep 2013, at 11:34, Tony Moore wrote:
>> > On 14 Sep 2013, Gerald Holdsworth <gerald@hollypops.co.uk> wrote:
> >
> > [snip]
> >
> > > I have a RISC OS 4.39 HostFS disc image from RedSquirrel, with
> > > tons of applications in it, and want to open these in RPCemu...but
> > > one can't just drag the entire disc image into an RPCemu HostFS
> > > directory, as both treat filetypes differently.
> >
> > Could you send the files over the network?
>
> Would still need to fire up Red Squirrel.

Is that a problem? I know nothing about Red Squirrel, btw.

> Having thought about it, I'll need to zip them up anyway as I want to
> eventually transfer them to a real Risc PC...

As you say, you'll need to fire up RS to zip the files so, if RS and
RPCEmu can exist on the same network, a direct transfer would seem to be
the simplest way of copying the files.

I regularly transfer files, via ShareFS, over the network between my
RiscPC and RPCEmu, running on a Win7 machine, _without_ zipping them, so
I wonder why you'd need to do that.

> just bought a RPC600 with 16bit sound upgrade, Simtec USB Podule,
> NET100 NIC, and best of it, a Kinetic processor! These will, of
> course, be going into my RPC700, once all the other bits I've ordered
> have arrived (replacement battery, 32GB solid state drive, and Vpod
> graphics card).

Good luck!

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Filetype translation

On 15 Sep 2013, at 11:34, Tony Moore wrote:

> On 14 Sep 2013, Gerald Holdsworth <gerald@hollypops.co.uk> wrote:
>
> [snip]
>
>> I have a RISC OS 4.39 HostFS disc image from RedSquirrel, with tons of
>> applications in it, and want to open these in RPCemu...but one can't
>> just drag the entire disc image into an RPCemu HostFS directory, as
>> both treat filetypes differently.
>
> Could you send the files over the network?
>
> Tony

Hi Tony,

Would still need to fire up Red Squirrel.

Having thought about it, I'll need to zip them up anyway as I want to eventually transfer them to a real Risc PC...just bought a RPC600 with 16bit sound upgrade, Simtec USB Podule, NET100 NIC, and best of it, a Kinetic processor! These will, of course, be going into my RPC700, once all the other bits I've ordered have arrived (replacement battery, 32GB solid state drive, and Vpod graphics card).

However, would still like that functionality in RPCemu.

Cheers,

Gerald.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Filetype translation

On 14 Sep 2013, Gerald Holdsworth <gerald@hollypops.co.uk> wrote:

[snip]

> I have a RISC OS 4.39 HostFS disc image from RedSquirrel, with tons of
> applications in it, and want to open these in RPCemu...but one can't
> just drag the entire disc image into an RPCemu HostFS directory, as
> both treat filetypes differently.

Could you send the files over the network?

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Changes to the RISC OS GUI in #1342

On 14 Sep 2013, Bernard Boase <b.boase@bcs.org> wrote:

[snip]

> ... moving the mouse pointer around in a <textarea> still produces
> non-display of characters to the left &/or right of the pointer during
> editing, just as it did before #1342.

Try setting scale view to 100%

Tony

Re: netsurf: branch master updated. release/3.0-562-g951ad51

On Sat, 14 Sep 2013 08:27:51 +0100, Commit Mailer wibbled on for an age:

> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=951ad51cd45ba2e5f49fab169ccbabc8f98a5185
> commit 951ad51cd45ba2e5f49fab169ccbabc8f98a5185
> Author: Michael Drake <tlsa@netsurf-browser.org>
> Commit: Michael Drake <tlsa@netsurf-browser.org>
>
> Add functions to get first selected hotlist/global_history node data.

There seems to be a problem with the nsurl* these are returning - I'm
getting nsurl_ref crashing if I pass them to any function (eg.
browser_window_navigate)

Chris

[Rpcemu] Filetype translation

Hi all,

Is there a way to specify the translation of Windows/Mac files to RISC OS filetypes in RPCemu?

I have a RISC OS 4.39 HostFS disc image from RedSquirrel, with tons of applications in it, and want to open these in RPCemu...but one can't just drag the entire disc image into an RPCemu HostFS directory, as both treat filetypes differently. At the moment, my only solution would be to try and fire up RedSquirrel and ZIP each and every application (or folders of them), then bring these across to RPCemu. However, if there is someway of telling RPCemu that an '.oby' file is a RISC OS Obey file, for example, it would make life so much easier...IIRC, RS has all these definitions in a text lookup file.

Cheers,

Gerald.

From the MacBook Air of Gerald Holdsworth
www.geraldholdsworth.co.uk
www.hollypops.co.uk

Re: Changes to the RISC OS GUI in #1342

On 8 Sep, Steve Fryatt <lists@stevefryatt.org.uk> wrote:

> This is just a heads-up to those using #1342 or later on RISC OS: I've
> made some major changes to the dragging and mouse tracking code, which
> could potentially affect lots of areas of the browser (save dialogues;
> text selection; drag-and-drop; toolbar editing; treeview windows;
> window scrolling).

Interesting, but moving the mouse pointer around in a <textarea> still
produces non-display of characters to the left &/or right of the
pointer during editing, just as it did before #1342.

Bugs reported in February 2013 (and earlier) seem to suggest that work
has been done on making <textarea> handling more robust. So is my
problem a known one, or one that is related to your mouse tracking
code, or is it just my system experiencing some problem in keeping the
window fully refreshed?

Iyonix, 5.18, Geminus, #1352.

--
Bernard

AGM minutes

Here are the minutes of the 2013 NetSurf AGM.

Thanks to Daniel Silverstone for recording them.

---------------------------------------------------------------------------


NetSurf AGM
===========

Attendees
---------

* Daniel Silverstone
* Vincent Sanders
* Michael Drake
* Rob Kendrick
* Chris Young
* François Revol

Welcome
-------

Michael welcomed everyone to the 2013 NetSurf AGM.

Secretary's Report
------------------

Last year's society committee consisted of:

Michael Drake, Chair
John-Mark Bell, Treasurer
Daniel Silverstone, Secretary

Last year's non-committee membership consisted of:

Rob Kendrick
Chris Young
Vincent Sanders
François Revol
Steve Fryatt

Nobody has left and noone has joined, thus the society stands at 8 members
and as such remains functional.

Treasurer's Report
------------------

Unfortunately we do not have an up-to-date treasurer's report at this time.
John-Mark is unable to attend.

However, we have an August 4th report:
<http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2013-August/003141.html>

Since August 4th, approximately 300 UKP has been spent on CI server
hosting for the coming year.

Chairman's Report
-----------------

The chairman's report can be found at:

<http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2013-August/003142.html>

Since this report, treeviews have been added. The only blocker against 3.1
is the reworking of forms.

Committee Election
------------------

I have received nominations and seconds for the incumbent society committee
members. No incumbent has declined the nominations. Thus the question to
vote on is "Should the incumbent committee serve for another year?".

Everyone present voted in favour of the incumbents.

Since no votes against were registered before the meeting, the incumbents
are hereby elected to remain as the service committee for the coming year.

Project steering
----------------

Michael reiterated that the short-term project goal is to get 3.1 done
since the release of 3.0 was somewhat rushed. Longer term, our goal
remains dynamic layout and better JS integration, along with correcting
our CSS selection performance which is currently very poor.

Vincent pointed out that JavaScript integration needs the binding
generator's support for inherited elements to be improved and that after
then, it is mostly just writing the DOM bindings. Vincent even believes
that the bindings may be able to be automatically built, but he lacks time
to achieve this for now.

Daniel suggested a hack weekend. Michael agreed and Vincent offered to
host. Rob pointed out that Codethink could possibly host too if people
fancied Manchester instead of Cambridge. Michael suggested we wait and
consult with John-Mark about dates etc. He also called for a possible
attendance list. Michael, Vincent, Daniel and Rob all indicated an
ability to attend.

AI: Vincent to liase with John-Mark and then make a plan for a hack
weekend.

Chris raised that printing gets mentioned to him. This comes back to
content cloning which is a known issue at this time. François asked how
much of printing is platform-specific. Initially printing would be
generating a PDF which makes it mostly core. Rob wondered if it might be
worth writing a PostScript render backend. Michael reminded the meeting
that we'd need stylesheet selection, @media handling etc. and for the
layout engine to properly support pagination.

Daniel proposed that we shelve printing for now, and reconsider it when
determining requirements for the new layout engine. Everyone agreed.
Michael suggested we might be able to achieve some kind of poor quality
print short-term if we wanted.

A.O.B
-----

### Bug Trackers

Michael raised that the SourceForge bug tracker no longer functions in
NetSurf. Rob suggested that we could fire up a BTS on one of the machines
we use for CI. Daniel asked if Rob had any suggestions for which BTS to
run. Rob stated a dislike for them all.

Vincent pointed out that there's plenty of headroom on the CI master
machine now. Mantis can be run in a VM with one CPU and 512MB of RAM.
Chris indicated that he ran a Mantis for a while and that it worked with
NetSurf when he did. Michael and Vincent both raised importing the old BTS
data.

AI: Rob Kendrick to research bug trackers and suggest one which can be run
reasonably easily and will work with NetSurf. Expectation is Mantis
but there are other options.

### Continuous Integration

Vincent reported:

The CI system now consists of four systems. Two are MacOS-X systems and
two are x86 VMs hosted by Mythic Beasts. The Mythic beasts systems have 2
gigs of RAM each and we run Jenkins and the downloads sites on one and use
the other as a build slave.

Vincent raises the question: What about continued support for the
platforms not under CI, and also MacOS-X PPC. Michael pointed out that
this involves the BeOS port since that cannot be CI'd at this time, and
that MacOS-X PPC cannot run Java 1.6 which prevents us from upgrading
Jenkins.

Michael asked if it is impossible to cross-build the MacOS-X port. Vincent
said yes, hence the native builders.

François pointed out that for BeOS/Haiku to be CI'd, he'd need to sort
out the cross-toolchain. Since the toolchain is not meant for building
outside of Haiku's build process it will be a pain. Rob pointed out that
we'd want the cross-environment to be prepared in the same way as all the
other systems and François agreed.

Vincent pointed out that if we can run Java 1.6 on Haiku then we could
host a "real" build slave on it. François pointed out that non-gui stuff
might be possible and Vincent agreed that the Jenkins slave is headless.
In theory therefore it might be possible.

AI: François to research the build options for Haiku and BeOS and come
back to the group with a proposal for getting it into CI or else
dropped.

Michael advocated dropping MacOS-X PPC after 3.1. Vincent explained that
the PPC port of MacOS-X doubles the build time on the CI.

Michael asked Chris if the Amiga CI builds see much action. Chris said
that he knows of a few people who download them. Vincent asked if there
was any way to improve matters and Chris asked for a 'With JS' build.
Vincent asked Chris to update the Amiga cross-toolchain to the appropriate
Spidermonkey release and then he will enable them.

AI: Chris to sort out Spidermonkey for the Amiga cross-toolchain

Closing
-------

Michael thanked everyone for attending. Daniel indicated that these
minutes will be posted to the mailing list soon.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

AGM this evening

Final reminder:

AGM will be at 20:00 UK time, Thursday 12th September.

It will be on the NetSurf IRC channel on Freenode.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Atari daily build 1344

>> (2.230000) desktop/global_history.c global_history_init 715: Loading
>> global history
>> ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion
>> `win != ((void *)0)' failed.

Should be fixed in the next auto-build.

Greets,
Ole

Re: Atari daily build 1344

Hello Peter,

> I am running from /u/g/Applicatiions/netsurf as I always do.
> Below id th result of running with -v
>
> Strangely I cannot pipe this output to a file.

You have to pipe the error output, not stdout. I believe it's done like
this:

ns.prg &> ns.log

>
> (2.230000) desktop/global_history.c global_history_init 715: Loading
> global history
> ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion
> `win != ((void *)0)' failed.
> (

I think the problem is related to the changes to the TreeView.
I will have a look at it. Thanks for testing the daily builds and
reporting
the problem.

Greets,
Ole

Re: mail

In article <20130910114927.GQ25754@kyllikki.org>,
Vincent Sanders <vince@kyllikki.org> wrote:


> ----- Forwarded message from Murat Gocmen <gocmenmurat@gmail.com> -----

> I am not even sure if somebody going to have this email, but i will try,

The correct place is the netsurf-dev mailing list.

> lately i have seen a different behaviour on border shorthand setting,
> when setting border: xxx it was setting the border color value,
> pathc is attached,

I've applied your patch with this change:

> + error = css__stylesheet_style_appendOPV(style_style,
^^^^^^^^^^^

Should be color_style there.

Thanks for the fix.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Atari daily build 1344

On Tue, 10 Sep 2013 12:00:52 , netsurf-users-request@netsurf-browser.org wrote:
> Send netsurf-users mailing list submissions to
> Date: Mon, 09 Sep 2013 13:35:53 +0100
> From: Michael Drake <tlsa@netsurf-browser.org>
> Subject: Re: Atari daily build 1344
> To: <netsurf-users@netsurf-browser.org>
> Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
>
> > bash-2.05a# ./ns020.app
> > ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion `win != ((void *)0)' failed.
> > Abort
>
> Can you get a backtrace? Also, run with -v and put the log output in a
> pastebin[*].
>
>
> [*] e.g. http://pastebin.com/
>

I am running from /u/g/Applicatiions/netsurf as I always do.
Below id th result of running with -v

Strangely I cannot pipe this output to a file.


Peter


(0.000001) utils/nsoption.c nsoption_read 605: Sucessfully opened '/g/Applications/netsurf/Choices' for Options file
(0.040000) atari/gui.c main 1074: Initialising core...
(0.040001) desktop/netsurf.c netsurf_init 143: NetSurf version '3.1 (Dev CI #1344)'
(0.040002) desktop/netsurf.c netsurf_init 150: NetSurf on <FreeMiNT>, node <Milan>, release <1.19a>, version <4.8>, machine
<milan> (0.040003) utils/messages.c messages_load 124: Loading Messages from '/g/Applications/netsurf/res/messages'
(0.135000) image/image_cache.c image_cache_init 380: Image cache initilised with a limit of 5000007 hysteresis of 1000001
(0.135001) render/html_css_fetcher.c html_css_fetcher_initialise 63: html_css_fetcher_initialise called for x-ns-css
(0.145000) content/fetchers/curl.c fetch_curl_register 167: curl_version libcurl/7.28.0 OpenSSL/1.0.1c zlib/1.2.7 c-ares/1.9.1
(0.570000) utils/useragent.c user_agent_build_string 68: Built user agent "NetSurf/3.0 (FreeMiNT)"
(0.570001) content/fetchers/curl.c fetch_curl_register 213: ca_bundle: './res/cabundle'
(0.570002) content/fetchers/curl.c fetch_curl_register 217: ca_path: './res/certs'
(0.570003) content/fetchers/curl.c fetch_curl_register 229: cURL linked against openssl
(0.575000) content/fetchers/curl.c fetch_curl_initialise 286: Initialise cURL fetcher for http
(0.575001) content/fetchers/curl.c fetch_curl_initialise 286: Initialise cURL fetcher for https
(0.575002) content/fetchers/data.c fetch_data_initialise 65: fetch_data_initialise called for data
(0.585000) atari/findfile.c atari_find_resource 171: adblock.css (def: adblock.css)
(0.585001) atari/findfile.c atari_find_resource 174: checking ./res/adblock.css
(0.590000) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/adblock.css

(0.590001) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/adblock.css

(0.590002) atari/findfile.c atari_find_resource 171: default.css (def: default.css)
(0.590003) atari/findfile.c atari_find_resource 174: checking ./res/default.css
(0.590004) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/default.css

(0.595000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/default.css

(0.595001) atari/findfile.c atari_find_resource 171: internal.css (def: internal.css)
(0.595002) atari/findfile.c atari_find_resource 174: checking ./res/internal.css
(0.595003) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/internal.css

(0.600000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/internal.css

(0.600001) atari/findfile.c atari_find_resource 171: quirks.css (def: quirks.css)
(0.600002) atari/findfile.c atari_find_resource 174: checking ./res/quirks.css
(0.600003) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/quirks.css

(0.600004) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/quirks.css

(0.605000) atari/findfile.c atari_find_resource 171: user.css (def: user.css)
(0.605001) atari/findfile.c atari_find_resource 174: checking ./res/user.css
(0.605002) atari/findfile.c atari_find_resource 182: checking ./user.css
(0.605003) atari/findfile.c atari_find_resource 194: checking /home/.netsurf/user.css
(0.610000) atari/findfile.c atari_find_resource 218: checking user.css
(0.610001) atari/findfile.c path_to_url 88: path2url in: user.css

(0.610002) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/user.css

(0.610003) atari/findfile.c atari_find_resource 171: credits.html (def: credits.html)
(0.615000) atari/findfile.c atari_find_resource 174: checking ./res/credits.html
(0.615001) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/credits.html

(0.615002) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/credits.html

(0.615003) atari/findfile.c atari_find_resource 171: licence.html (def: licence.html)
(0.615004) atari/findfile.c atari_find_resource 174: checking ./res/licence.html
(0.620000) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/licence.html

(0.620001) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/licence.html

(0.620002) atari/findfile.c atari_find_resource 171: welcome.html (def: welcome.html)
(0.620003) atari/findfile.c atari_find_resource 174: checking ./res/welcome.html
(0.805000) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/welcome.html

(0.810000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/welcome.html

(0.810001) atari/findfile.c atari_find_resource 171: favicon.ico (def: favicon.ico)
(0.810002) atari/findfile.c atari_find_resource 174: checking ./res/favicon.ico
(0.810003) atari/findfile.c atari_find_resource 182: checking ./favicon.ico
(0.815000) atari/findfile.c atari_find_resource 194: checking /home/.netsurf/favicon.ico
(0.815001) atari/findfile.c atari_find_resource 218: checking favicon.ico
(0.815002) atari/findfile.c path_to_url 88: path2url in: favicon.ico

(0.815003) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/favicon.ico

(0.820000) atari/findfile.c atari_find_resource 171: netsurf.png (def: netsurf.png)
(0.820001) atari/findfile.c atari_find_resource 174: checking ./res/netsurf.png
(0.820002) atari/findfile.c atari_find_resource 182: checking ./netsurf.png
(0.820003) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/netsurf.png

(0.825000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/netsurf.png

(0.825001) atari/findfile.c atari_find_resource 171: icons/arrow-l.png (def: icons/arrow-l.png)
(0.825002) atari/findfile.c atari_find_resource 174: checking ./res/icons/arrow-l.png
(0.825003) atari/findfile.c atari_find_resource 182: checking ./icons/arrow-l.png
(0.830000) atari/findfile.c atari_find_resource 194: checking /home/.netsurf/icons/arrow-l.png
(0.830001) atari/findfile.c atari_find_resource 218: checking icons/arrow-l.png
(0.830002) atari/findfile.c path_to_url 88: path2url in: icons/arrow-l.png

(0.835000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/icons

(0.835001) atari/findfile.c atari_find_resource 171: icons/content.png (def: icons/content.png)
(0.835002) atari/findfile.c atari_find_resource 174: checking ./res/icons/content.png
(0.835003) atari/findfile.c path_to_url 88: path2url in: /g/Applications/netsurf/res/icons/content.png

(0.840000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/res/icons/content.png

(0.840001) atari/findfile.c atari_find_resource 171: icons/directory.png (def: icons/directory.png)
(0.840002) atari/findfile.c atari_find_resource 174: checking ./res/icons/directory.png
(0.840003) atari/findfile.c atari_find_resource 182: checking ./icons/directory.png
(0.845000) atari/findfile.c atari_find_resource 194: checking /home/.netsurf/icons/directory.png
(0.845001) atari/findfile.c atari_find_resource 218: checking icons/directory.png
(0.845002) atari/findfile.c path_to_url 88: path2url in: icons/directory.png

(0.850000) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/icons

(0.850001) atari/findfile.c atari_find_resource 171: icons/search.png (def: icons/search.png)
(0.850002) atari/findfile.c atari_find_resource 174: checking ./res/icons/search.png
(0.850003) atari/findfile.c atari_find_resource 182: checking ./icons/search.png
(0.855000) atari/findfile.c atari_find_resource 194: checking /home/.netsurf/icons/search.png
(0.855001) atari/findfile.c atari_find_resource 218: checking icons/search.png
(0.855002) atari/findfile.c path_to_url 88: path2url in: icons/search.png

(0.855003) atari/findfile.c path_to_url 122: path2url out: file:///g/Applications/netsurf/icons

(0.860000) content/llcache.c llcache_initialise 2303: llcache initialised with a limit of 15000023 bytes
(0.860001) atari/gui.c main 1080: Initializing GUI...
(0.860002) atari/findfile.c atari_find_resource 171: netsurf.rsc (def: ./res/netsurf.rsc)
(0.860003) atari/findfile.c atari_find_resource 174: checking ./res/netsurf.rsc
(0.865000) atari/gui.c gui_init 948: Using RSC file: /g/Applications/netsurf/res/netsurf.rsc
(1.195000) atari/gui.c gui_init 984: Enabling core select menu
(1.195001) atari/gui.c gui_init 987: Loading url.db from: ./res/url.db
(1.195002) content/urldb.c urldb_load 361: Loading URL file ./res/url.db
(1.260000) content/urldb.c urldb_load 535: Successfully loaded URL file
(1.265000) atari/gui.c gui_init 992: Loading cookies from: ./res/cookies
(1.410001) atari/gui.c process_cmdline 839: argc 1, argv 0x24bf8b0
(1.410002) atari/gui.c gui_init 1000: Initializing NKC...
(1.410003) atari/gui.c gui_init 1004: Initializing plotters...
(1.430000) atari/plot/plot.c plot_init 1530: Plot VDI handle: 46
(1.435000) atari/plot/font_freetype.c ctor_font_plotter_freetype 684: atari/plot/font_freetype.c: ctor_font_plotter_freetype

(1.435001) atari/findfile.c atari_find_resource 171: fonts/ss.ttf (def: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf)
(1.435002) atari/findfile.c atari_find_resource 174: checking ./res/fonts/ss.ttf
(1.460000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/ss.ttf

(1.540000) atari/findfile.c atari_find_resource 171: fonts/ssb.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraBd.ttf)
(1.540001) atari/findfile.c atari_find_resource 174: checking ./res/fonts/ssb.ttf
(1.565000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/ssb.ttf

(1.565001) atari/findfile.c atari_find_resource 171: fonts/ssi.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraIt.ttf)
(1.565002) atari/findfile.c atari_find_resource 174: checking ./res/fonts/ssi.ttf
(1.590000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/ssi.ttf

(1.590001) atari/findfile.c atari_find_resource 171: fonts/ssib.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraBI.ttf)
(1.590002) atari/findfile.c atari_find_resource 174: checking ./res/fonts/ssib.ttf
(1.615000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/ssib.ttf

(1.615001) atari/findfile.c atari_find_resource 171: fonts/mono.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf)
(1.615002) atari/findfile.c atari_find_resource 174: checking ./res/fonts/mono.ttf
(1.635000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/mono.ttf

(1.640000) atari/findfile.c atari_find_resource 171: fonts/monob.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf)
(1.640001) atari/findfile.c atari_find_resource 174: checking ./res/fonts/monob.ttf
(1.825000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/monob.ttf

(1.825001) atari/findfile.c atari_find_resource 171: fonts/s.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraSe.ttf)
(1.825002) atari/findfile.c atari_find_resource 174: checking ./res/fonts/s.ttf
(1.845000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/s.ttf

(1.850000) atari/findfile.c atari_find_resource 171: fonts/sb.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraSeBd.ttf)
(1.850001) atari/findfile.c atari_find_resource 174: checking ./res/fonts/sb.ttf
(1.870000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/sb.ttf

(1.875000) atari/findfile.c atari_find_resource 171: fonts/cursive.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoIt.ttf)
(1.875001) atari/findfile.c atari_find_resource 174: checking ./res/fonts/cursive.ttf
(1.895000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/cursive.ttf

(1.895001) atari/findfile.c atari_find_resource 171: fonts/fantasy.ttf (def:
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBI.ttf)
(1.895002) atari/findfile.c atari_find_resource 174: checking ./res/fonts/fantasy.ttf
(1.920000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/fantasy.ttf

(1.920001) atari/bitmap.c bitmap_create_ex 97: width 48 (rowstride: 192, bpp: 4), height 48, state 0
(1.920002) atari/bitmap.c bitmap_create_ex 126: bitmap 0x1ac645c
(2.120000) atari/gui.c main 1083: Initializing GUI2
(2.220000) atari/plot/font_freetype.c ft_face_requester 165: Loaded face from /g/Applications/netsurf/res/fonts/ss.ttf

(2.230000) desktop/global_history.c global_history_init 715: Loading global history
ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion `win != ((void *)0)' failed.
(

[gocmenmurat@gmail.com: i have a fix for libcss]

diff -rupN libcss-0.2.0/src/parse/properties/utils.c libcss-0.2.0.new/src/parse/properties/utils.c
--- libcss-0.2.0/src/parse/properties/utils.c 2013-04-19 19:40:31.000000000 +0100
+++ libcss-0.2.0.new/src/parse/properties/utils.c 2013-08-12 15:06:46.841815000 +0100
@@ -227,6 +227,14 @@ css_error css__parse_border_side(css_lan
goto css__parse_border_side_cleanup;
}

+ if (color) {
+ error = css__stylesheet_style_appendOPV(style_style,
+ CSS_PROP_BORDER_TOP_COLOR + side, 0,
+ BORDER_COLOR_CURRENT_COLOR);
+ if (error != CSS_OK)
+ goto css__parse_border_side_cleanup;
+ }
+
error = css__stylesheet_merge_style(result, color_style);
if (error != CSS_OK)
goto css__parse_border_side_cleanup;
recived in private mail, attached the patch from the url

----- Forwarded message from Murat Gocmen <gocmenmurat@gmail.com> -----

Date: Tue, 10 Sep 2013 12:17:49 +0100
From: Murat Gocmen <gocmenmurat@gmail.com>
To: jmb@netsurf-browser.org, vince@netsurf-browser.org
Subject: i have a fix for libcss

Hi All,

I am not even sure if somebody going to have this email, but i will try,

lately i have seen a different behaviour on border shorthand setting,

when setting border: xxx it was setting the border color value,

pathc is attached,

fyi,

I have passed the css test suite border shorhand properties test via this
patch,

Regards.
border_color-0.2.0.patch<https://docs.google.com/file/d/0B8t45OYNG_RsZlNxWXM4akhVcjA/edit?usp=drive_web>


----- End forwarded message -----

--
Regards Vincent
http://www.kyllikki.org/

Re: Automatic backend selection in nsfb

On 07/09/2013 18:26, Brad Conroy wrote:
> I have previously patched netsurf and a couple of test programs to automatically select the appropriate nsfb backend using getenv() if it is not provided as an arg, but it may be useful to have this as the default behavior.
> the following env variables are set:
> Wayland -> WAYLAND_DISPLAY
> xcb -> DISPLAY
> linux framebuffer -> FRAMEBUFFER (and possibly isatty()?)
>
> vnc -> check port 5900?
> able -> no idea
>
> For the ones I'm familiar with the order should be wayland,xcb,linuxfb,sdl but I am less familiar with able and vnc.
> I assume Able should fall somewhere around the linuxfb and vnc should
either be first (by checking port 5900)
> or required as an arg.

For SDL you'll want to check those, even though they aren't mandatory:
http://sdl.beuc.net/sdl.wiki/SDL_envvars

François.

Re: Atari daily build 1344

Am Montag, den 09.09.2013, 14:17 +0200 schrieb Peter Slegg
<p.slegg@scubadivers.co.uk>:
> I have just tride the 1344 daily build and it fails to start
> saying it can't find netsurf.rsc

There is an problem with some atari desktops and drive letters /
resource location. Did you try to run netsurf from the unified
filesystem (U:) ?
If not, please do so and report the results, thanks.

Greets,
Ole

Re: Atari daily build 1344

In article <0003b9c1.0234e500acf1@smtp.freeola.net>,
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

> bash-2.05a# ./ns020.app
> ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion `win != ((void *)0)' failed.
> Abort

Can you get a backtrace? Also, run with -v and put the log output in a
pastebin[*].


[*] e.g. http://pastebin.com/

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Atari daily build 1344

I have just tride the 1344 daily build and it fails to start
saying it can't find netsurf.rsc

>From the command line it give this:

bash-2.05a# ./ns020.app
ns020.app: atari/gemtk/guiwin.c:810: gemtk_wm_get_grect: Assertion `win != ((void *)0)' failed.
Abort


Peter

AGM this Thursday

Just a quick reminder:

AGM will be at 20:00 UK time, Thursday 12th September.

It will be on the NetSurf IRC channel on Freenode.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Changes to the RISC OS GUI in #1342

This is just a heads-up to those using #1342 or later on RISC OS: I've made
some major changes to the dragging and mouse tracking code, which could
potentially affect lots of areas of the browser (save dialogues; text
selection; drag-and-drop; toolbar editing; treeview windows; window
scrolling).

Everything that I've tried still seems to be working, but as ever I'm not
going to rule out the possibility that I've missed some bits of the GUI that
I've forgotten about or wasn't even aware existed. Testing and bug reports
would therefore be welcome.

The changes are to make it easier to understand and maintain the mouse
tracking code, as part of fixing issues in this area which came to light
with the new treeview displays (such as the hotlist).

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Re: Automatic backend selection in nsfb

On Sat, Sep 07, 2013 at 09:26:20AM -0700, Brad Conroy wrote:
> able -> no idea

ABLE is exciting and best ignored from this point of view.

B.

Automatic backend selection in nsfb

I have previously patched netsurf and a couple of test programs to automatically select the appropriate nsfb backend using getenv() if it is not provided as an arg, but it may be useful to have this as the default behavior.
the following env variables are set:
Wayland -> WAYLAND_DISPLAY
xcb -> DISPLAY
linux framebuffer -> FRAMEBUFFER (and possibly isatty()?)

vnc -> check port 5900?
able -> no idea

For the ones I'm familiar with the order should be wayland,xcb,linuxfb,sdl but I am less familiar with able and vnc. I assume Able should fall somewhere around the linuxfb and vnc should either be first (by checking port 5900) or required as an arg.

Re: New treeview

In article <538572d21etlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:

> While removing the old treeview, I found a couple of front ends were
> using the treeview internals directly for things like menu based access
> to the hotlist. This is impossible now. I'll add an iteration API to
> the hotlist module.

Added that now. Let me know if it's not sufficient.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: 3.1 (Dev CI #1330)

In article <538573f7ddtlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:

> The glyphs we need added are:

> http://www.fileformat.info/info/unicode/char/25b8/index.htm

> and

> http://www.fileformat.info/info/unicode/char/25be/index.htm

> If anyone can do that, please get in touch.

Way beyond my competence level! Though I notice Dingbats does have a
down-pointy triangle if that helps anyone else! Tho' it also has an EFF
logo, so perhaps not.

John

Re: 3.1 (Dev CI #1330)

In article <53857230d8JohnRW@ukgateway.net>,
John Williams <JohnRW@ukgateway.net> wrote:

> My treeview display pluses and minuses have changed to 25/b8 and 25/be.

They should be triangles, but you don't have any fonts containing the
correct glyphs. Here's how it should look:

http://www.netsurf-browser.org/temp/treeview/

Since the default fonts on RISC OS don't seem to have those glyphs we'll
need someone to add them to the !NetSurf.Resources.Fonts/NSSymbol font.

The glyphs we need added are:

http://www.fileformat.info/info/unicode/char/25b8/index.htm

and

http://www.fileformat.info/info/unicode/char/25be/index.htm

If anyone can do that, please get in touch.

Cheers,

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: 3.1 (Dev CI #1330)

In article <53857230d8JohnRW@ukgateway.net>,
John Williams <JohnRW@ukgateway.net> wrote:

> My treeview display pluses and minuses have changed to 25/b8 and
> 25/be.

Probably because you do not have a font with the correct characters -
the treview code has been rewritten recently.

Michael Drake, who has done the work, wrote on the Netsurf dev list
in reply to a similar comment

--------------------------------------------------------------------
> Same result - works just fine, but I see 25b8 and 25be instead of
> the triangles.

Yeah, as I said, it seems the default RISC OS fonts don't supply those
glyphs. We'll need to add them to the
!NetSurf.Resources.Fonts.NSSymbol
font.

Anyone want to have a crack at that?
---------------------------------------------------------------------

--
Chris Johnson

Re: New treeview

In article <53826752d2tlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:

> Over the weekend I intend to make NetSurf use the new treeview, and
> remove the old one. The temp_treeview_test option will be removed.

That's now done.

All front ends are now using the old tree.{c|h} API as a compatibility
layer for the new treeview functionality. They should be updated to use
the new core hotlist, global_history, cookie_manager, and sslcert_viewer
modules instead.

While removing the old treeview, I found a couple of front ends were using
the treeview internals directly for things like menu based access to the
hotlist. This is impossible now. I'll add an iteration API to the
hotlist module.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

3.1 (Dev CI #1330)

My treeview display pluses and minuses have changed to 25/b8 and 25/be.

John