Embeddable web view in apps
by Richard Gale
It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
Thanks,Richard.
8 years, 7 months
AGM minutes
by Michael Drake
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/20...>
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/20...>
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/
9 years, 4 months
Bugs, their care and stomping
by Vincent Sanders
The NetSurf team are pleased to announce the availability of a new bug tracker [1]
The new tracker uses mantis [2] software which is usable from NetSurf
This move has been necessitated because of several issues, principally:
- The SourceForge issue tracking system has been upgraded and is now
unusable from NetSurf
- The advertisements on the site have become aggressively invasive
- The reliability of the site has come into question.
We have imported the bugs from SourceForge although this has resulted
in a renumbering of identifiers (bug numbers).
We have been able to put a link back to the old sourceforge bug
numbers in the "Additional Information" of every imported bug.
Please do not use the SourceForge tracker for any new bugs or update
any old ones there as they will be ignored.
Accounts
--------
We have created users within the new system for everyone who has
reported a bug. For most imported users the email address used was
their sourceforge contact address [3]
The new system does not allow for anonymous issue reporting, if this
is a problem for you we thank you for your opinion but this decision
is not negotiable.
To login please use the lost password interface [4] to update your
details if you wish.
If a user needs the address associated with their account altering and
cannot access it through sourceforge please contact us [5] giving as
much information as possible (including the user id and some
reasonable argument that the account is yours - we will set the
address to where you send the mail from)
Accounts have been created manually for the many users who usefully
put their contact details within their reports, additionally their
email details have been removed from the publicly visible reports
which should reduce spam harvesting.
We assure all users we will never use the email addresses given to the
system other than to reply to their bug reports.
New and existing bugs
---------------------
Updates to bugs will (by default! this is configurable for each user
[6]) result in the reporter receiving an email. If you wish to update
a bug please use the web interface, replying to the emails means a
developer has to manually copy the reply to the bug. We may reconsider
changing the reply address to refuse mail if this becomes a burden.
New reports should contain as much information as the reporter can
provide we give some guidence [7] but ultimately the more information
you provide the more likely we can reproduce the issue and the more
likely it is to get resolved.
Debugging is hard [8] please do not have unreasonably high
expectations, we did *not* intend to have the bug that you found,
please do not take it personally.
I have currently triaged just over 10% of the open bugs and will make
my way through those that remain over the forthcoming weeks. Please
understand that there are very few active developers and many open
bugs so this work goes slow.
I have to be pretty harsh in my triage and will close incomplete bugs
(especially anonymous ones) without a detailed examination. These may
be reopened by the reporter but I request that as much information is
provided as you can.
What things mean
----------------
I know some reporters are already misunderstanding what the various
fields in a report are for, especially the severity and status
fields.
Severity refers to how severe the impact is on the project overall
i.e. if the bug causes a crash in normal operation (crash severity)
and is *not* a reflection on how important the bug is (we specifically
do not have a priority field for that). To be clear the *default* of
minor means, in this context, that the bug does not make the browser
unusable for *everyone*
Status is related to the bug work flow within the netsurf team. It
starts at new when the bug is reported, gets set to feedback when we
need more information from the user or a user reopens an unresolved
issue.
The acknowledged status means a developer has at least looked at
the report but not reproduced the issue whereas confirmed shows they
have reproduced it (not the reporter, we know they managed it!).
The assigned status means that one of the developers has decided they
are the best person to fix the issue and are actively examining the
problem. We are also using the assignment to the import user as a flag
that basic triage has not yet been performed on the bug.
Finally the resolved status implies that the resolution field should
be looked at to see how the issue was resolved and the closed status
implies the developer has finished with the report and no additional
activity will be made on the issue.
[1] http://http://bugs.netsurf-browser.org
[2] http://www.mantisbt.org/
[3] if the userid on sourceforge was kyllikki the email used was kyllikki(a)users.sourceforge.net
[4] http://bugs.netsurf-browser.org/mantis/lost_pwd_page.php
[5] help(a)netsurf-browser.org
[6] http://bugs.netsurf-browser.org/mantis/account_prefs_page.php
[7] http://bugs.netsurf-browser.org/
[8] Everyone knows that debugging is twice as hard as writing a program in the first place. - Brian Kernighan "The Elements of Programming Style", 2nd edition, chapter 2
--
Regards Vincent
9 years, 4 months
RISC OS Hotlist Fixes
by Steve Fryatt
I've updated the RISC OS front-end to properly support the new hotlist
tool in the URL bar (ie. handle mouse clicks, confirm before deleting
things and provide interactive help). Because I've added some items to
FatMessages and therefore can't push them, the changes are in a branch
here:
http://git.netsurf-browser.org/netsurf.git/log/?h=stevef/hotlist
It builds and tests OK for me, so should be OK to merge in to master.
The following tokens are new in FatMessages, and so could do with
translations if anyone can help.
all.RemoveHotlist
all.Remove
all.DontRemove
ro.HelpToolbarFav
ro.HelpToolbarHot
The three confirmation texts are currently set to 'all' to match all the
other similar entries in the file; they could be made 'ro' specific if
that's considered better, although in theory they would apply to other
front-ends implementing this functionality in the future.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
9 years, 5 months
[RFC][PATCH] filename_initialize() fix
by François Revol
It would seem filename_inizialize() is buggy:
It tries to mkdir("") which obviously fails, and they fails if some dirs
already exist (which is true for /tmp usually)...
This seems to fix it for the Haiku port (which didn't call it yet but
used a native call instead with the wrong permissions).
I don't think it breaks any other port using it (win, RO).
Comments?
François.
9 years, 5 months
[PATCH] [libcss] C89
by François Revol
diff --git a/src/select/hash.c b/src/select/hash.c
index 6fc08d7..bf7c741 100644
--- a/src/select/hash.c
+++ b/src/select/hash.c
@@ -856,8 +856,8 @@ css_error _insert_into_chain(css_selector_hash *ctx,
hash_entry *head,
#endif
if (prev == NULL) {
- entry->next = entry;
hash_entry temp = *entry;
+ entry->next = entry;
*entry = *head;
*head = temp;
} else {
9 years, 5 months
Re: Bugs, their care and stomping
by Vincent Sanders
On Wed, Dec 18, 2013 at 03:15:08PM +0000, Harriet Bazley wrote:
> On 18 Dec 2013 as I do recall,
> Vincent Sanders wrote:
>
> > On Wed, Dec 18, 2013 at 02:29:06AM +0000, Harriet Bazley wrote:
> > > On 17 Dec 2013 as I do recall,
> > > Vincent Sanders wrote:
> > >
> > > [snip]
> > >
> > >
> > > > We have created users within the new system for everyone who has
> > > > reported a bug. For most imported users the email address used was
> > > > their sourceforge contact address [3]
> > > >
> > > Oh -- oops, there's two of me now, then...
> >
> > Only one now, I moved all 59 of your old reports to your new user
> >
> Thanks - could you possibly delete the old (users.sourceforge.net) user,
> as I'm receiving two copies of all the notifications via the two
> different addresses?
I already did, the sourceforge adress is no longer in our database
>
> --
> H. Bazley
>
> Wimbledon SW19 020 8543 0362
>
--
Regards Vincent
http://www.kyllikki.org/
9 years, 5 months
