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, 4 months
Long URLs on RISC OS
by Steve Fryatt
I've made some changes to the RISC OS front-end to partly address tickets
#390 and #2053: URL entry fields are now 2047 characters long (which appears
to be up there with the "best of the worst" of the mainstream browsers), and
changing this is now a case of altering a #define in riscos/gui.h and
recompiling. It's a compromise, as RISC OS's inability to change the size of
writable fields on the fly means that longer sizes waste more memory for
each window that's opened.
In addition, over-size URLs are handled more gracefully by browser toolbars:
the user gets a warning and the field is cleared and terminated safely.
Finally, I've fixed a bug where it was possible for toolbar URLs to miss the
conversion from UTF8 into local encoding under some (probably unlikely)
circumstances.
If anyone has any thoughts about the advisability (or otherwise) of these
changes, I'd welcome comments. Otherwise, they are in the branch
http://git.netsurf-browser.org/netsurf.git/log/?h=stevef/urlsize
if someone with access outside of riscos/ could merge them with the master?
There's a new message token in FatMessages, which could do with the non-en
forms translating into appropriate languages: xx.ro.LongURL is the warning
the user gets of URLs which are too long to display.
PS: Should I be deleting my branches once they're merged? If so, what's the
preferred way to do it?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
9 years, 1 month
[PATCH] Partial build fix for atari toolchains on debian unstable
by François Revol
It seems automake on latest Debian is too recent for the autoconf we
want to use.
This patch forces using aclocal/automake 1.11 which seems to work correctly.
It still fails later trying to build pml though:
...
make -f Makefile.32 libpml32.a
make[2]: Entering directory
`/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
-o cadd.o cadd.c
cadd.c:69:19: fatal error: stdio.h: No such file or directory
Same for m5475-atari-mint.
François.
9 years, 1 month
document.write but not document.writeln
by Dave Higton
I'm completely new to JavaScript.
I tried a small number of elementary JavaScript examples this evening
with NS 1627, and it appears that document.write works, but
document.writeln seems to output nothing. Is that what you would
expect?
Is there any page where the implementation status of JavaScript
features or functions within NS is tracked for users to see? It
seems to me that it would be useful for those of us who are hoping
to write pages or sites likely to be visited by NS users, and
maybe as a help for those of us who are learning JavaScript too.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
9 years, 2 months
Re: [PATCH] buildsystem: add support for multilib
by David Tardon
Hi,
On Sun, Jan 12, 2014 at 10:30:22AM +0000, Rob Kendrick wrote:
> On Sun, Jan 12, 2014 at 09:38:03AM +0100, David Tardon wrote:
> > Hi,
> >
> > this patch and the follow ups for libraries (only those I am interested
> > in, sorry) make it much easier to build on typical Linux distributions,
> > where 64-bit libs are put into /usr/lib64.
>
> What is typical? The idea of allowing where to put the libraries to be
> more flexible is nice, but I've never used a Linux distribution that put
> libraries for the running system anywhere other than in /usr/lib/
Theoretically, any distribution that follows FHS, e.g., Fedora / CentOS
or SuSE. Debian and Ubuntu do not do that (I thought they did :-) and
instead use more powerful multi-arch concept (see
https://wiki.debian.org/Multiarch/TheCaseForMultiarch), which puts
libraries into architecture-specific subdirectories of /usr/lib, e.g.,
/usr/lib/x86_64-linux-gnu. Gentoo seems to use /usr/lib for packages
that do not support multilib and either /usr/lib64 or /usr/lib32 for
those that do. Archlinux always puts native architecture libraries in
/usr/lib, but on 64-bit system it allows 32-bit libraries in /usr/lib32.
Note that this is mostly pretty old stuff: I remember /usr/lib64 being
used in Fedora 8 6 years ago.
I have not checked any other distributions, but I hope this is
compelling enough to show that the extra abstraction is needed.
D.
9 years, 2 months
[PATCH] buildsystem: add support for multilib
by David Tardon
Hi,
this patch and the follow ups for libraries (only those I am interested
in, sorry) make it much easier to build on typical Linux distributions,
where 64-bit libs are put into /usr/lib64. This patch does not change
anything by itself: unless a library is adapted to take advantage of it,
it builds (and installs) just like before.
D.
9 years, 2 months
