Treeview status
by Michael Drake
The core treeview code behaves a bit better now. The main improvements
are to mouse input handling, textarea editing and tree rendering.
The GTK and RISC OS front ends passing of browser_mouse_state has also
been fixed for various faults. I believe Chris has updated the Amiga
front end's browser_mouse_state setup too.
There are still some remaining issues. Key ones are:
CORE1: The core now supports arbitrary line heights, but this is
currently set to a fixed 20px instead of being based on the
font size. This is because in the GTK front end, the desktop
dpi is not available at the time the trees are initialised and
generated at startup. See GTK1.
CORE2: Selected nodes aren't updated as you drag.
CORE3: The core draws its own caret instead of calling the front end
to draw its own caret.
CORE4: The path to the icon directory is stored in a Choices option.
If this gets saved to the Choices file, and the location
of the icons changes, it will never find them and there is no
way to update the option. Maybe it should use the resources
path and add the icons sub directory to that or something.
RISC OS1: If you start editing a hotlist entry by selecting it and then
using the Selection > Edit menu, if you press the SHIFT key, it
ends the edit as if you'd pressed escape. If you type some
text before pressing SHIFT, it behaves correctly. The core
does not seem to get given the SHIFT keypress when it fails.
I don't know enough about RISC OS to know what might be
happening here. If you start the edit by CTRL+Clicking or
ALT+Clicking the text, SHIFT behaves correctly.
RISC OS2: While editing text in a treeview textarea, text selection
drag redraws are a bit broken. This could well be the core,
but it works on the GTK front end.
GTK1: The GTK front end doesn't set up the dpi until a browser window
is opened. The treeview code needs it when its initialised,
which happens before this.
With respect to NetSurf 2.7 release, my evaluation is:
NetSurf 2.7 Blockers:
+ RISC OS1
NetSurf 2.7 Blockers if not too difficult
+ GTK1
+ CORE1 (trivial, after GTK1 is done)
+ CORE4
Any comments?
If GTK1 is fixed, I'll fix CORE1. I will also do CORE2 if it doesn't look
like too much work.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
11 years, 7 months
Failed creating namespace xml
by Chris Young
Should I be concerned about this?
(17.250903) content/content.c content_create 463: url http://www.google.co.uk/ -> 0x5588c8f0
(17.251165) content/content.c content_add_user 1002: content http://www.google.co.uk/ (0x5588c8f0), user 0x6ebe9c18 0x565a97f8
(17.253761) render/hubbub_binding.c create_namespaces 311: Failed creating namespace xml
ISTR reading somewhere that libxml2 won't create namespaces called
"xml", but does this impact on NetSurf in any way? Surely hubbub
binding shouldn't be resorting to libxml2 calls?
Chris
11 years, 7 months
Re: Building the amiga frontend for AmigaOS 3
by Bernd Roesch
Hello Chris
On 07.01.11, you wrote:
> On Fri, 07 Jan 2011 20:43:14 +0200, Bernd Roesch wrote:
>
>>> MUI is not supported on OS4, ie. no updates. It's fine for
>>
>>> but zune is the furtherdevelop of MUI and its opensource.its some years ago port from sebastian
>> Bauer to OS4.
>
> First I've heard of this port, it certainly isn't public.
I dont know if that is finish and really work, but in zune source can see lots of amigaos4 ifdefs
and some extra files only for OS4 and os4 makefiles
I guess Sebastian have give it up, because MUI programs use lots of illegal hacks and zune was not
very compatible to replace MUI in that days.but since AFA use zune YAM, simple mail and other big
MUI programs work on zune ok.
I add in AFA a way to use zune and MUI together, and if a program open zune.library then zune is
use.
there is a zune promoter program here, so a user can to add the program to list so it open instead
muimaster.library zune.library
thats possible in OS4 too, i have suggest that for AROS 68k too.
maybe when OS4 OWB use MUI too and its seen by all that the friedens are not able to port firefox in
stable way) there is more intresting to use zune on OS4.
>
> Chris
Regards
11 years, 7 months
Re: Building the amiga frontend for AmigaOS 3
by Chris Young
On Fri, 07 Jan 2011 20:43:14 +0200, Bernd Roesch wrote:
> > MUI is not supported on OS4, ie. no updates. It's fine for
>
> >but zune is the furtherdevelop of MUI and its opensource.its some years ago port from sebastian
> Bauer to OS4.
First I've heard of this port, it certainly isn't public.
Chris
11 years, 7 months
Building the amiga frontend for AmigaOS 3
by John-Mark Bell
Recently, I've been playing around with getting cross-compilation
toolchains created for all the platforms we currently support. This is
in its early stages, and we're currently missing toolchains for most
platforms -- something that will be addressed as time allows.
As an exercise[1] to remind myself of the magic required to build a
cross compilation toolchain from scratch, I started with creating a
toolchain[2] capable of building binaries for AmigaOS 3. (Whether the
resulting binaries work is a different matter and I'm currently
uninterested in finding out one way or another).
Given that, I figured that I may as well see how much of the existing
AmigaOS 4 frontend builds with it. One trivial compatibility header
later, and we get the attached buildlog.
Given the totality of my AmigaOS knowledge can be written on the back of
a postage stamp, it'd be helpful if people who do have a clue could
provide suggestions as to the most sensible way to go about resolving
the remaining issues (ideally without introducing too many invasive
changes, as I'd rather avoid a maintenance nightmare)
J.
1. Amongst other things -- there was clearly an ulterior motive.
2. GCC 4.5.1 + Binutils 2.14 (ugh! old!) + Clib2 + OS 3.9 NDK
11 years, 7 months
Current state of Libdom
by alsaf
Hi
I just want to make sure my understanding of the current state of libdom
is correct.
The library is currently still in progress and that progress measured by
testing it with xml files stored in location
libdom/test/testcases/tests. I'm assuming that once the program is
successfully run when using the compile command make test then the
library is complete?
11 years, 7 months
Building netsurf on Mac OS X with framebuffer target
by Sven Weidauer
With these patches netsurf can be built on Mac OS X 10.6 (maybe earlier - not checked). It should be either built without libpng and libmng or those should be installed to /user/local before, so the build system finds them. The makefiles don’t find the versions provided by OS X.
I also attached a makefile to build libmng on OS X, since they don’t provide one.
11 years, 7 months
Re: Atari Patch
by m0n0
Hello,
I fixed the issues...
1. The min/max & ceilf macros are now handled within utils/utils.h
2. scancode.h owned by Borland was removed. An alternative lib is used
- CFLIB, this lib is licensed under LGPL. Does that matter?
This svn diff was a diff against revision 11217
Greets,
m
11 years, 7 months
Atari Patch
by m0n0
Hello,
this is the output of "svn diff" (agains rev. 11188) - is that enough
for patching? Or should I use the diff tool?
Probably my patch gets rejected for several reasons, but this is more a
test, so I can provide an corrected patch the next time :)
This patch adds support for the Atari OS. It misses several features
especially an off-screen renderer and the treeview Windows like hotlist,
history & SSL Cert info.
It isn't compatible with planar based graphics cards (planar video
memory systems are not so unusually with Atari Systems, but this port is
not written with the "Low-Fi" Atari-machines in mind), - at least not
when bitmaps are enabled.
This version was tested under aranym (Atari VM) & Atari Falcon CT60 &
Atari Falcon 030 with planar graphic system ( Bitmaps turned off ).
There is still a lot to do, but I think adding it to the SVN will be an
good help for me... and when looking at the windows version, I believe
you don't have to fully support all the features that NetSurf
implements.
Hope this (or probably corrected version) will be added to the svn!
Thanks to all the list member who helped out when I had problems! :)
Greets,
mono
11 years, 7 months
