Friday, 9 May 2014

Re: Core browser functionality

On Fri, 9 May 2014 11:44:15 +0100, Vincent Sanders wrote:

> My first addition would probably be to move the gui_factory operation
> table functionality and cause it to be used for the ns_register() very
> early in all the frontends main() which should remove some of teh
> issues ChrisY has experienced as fallout from my rcent refactors.

I don't know if you saw my other note, but doing the registration
early has stoped the crashing, but it still hangs in the vmkpath
function. I haven't had chance to investigate further, but it looks
like there might be something wrong in that function as well as the
issue of the operations table.

When I soft reboot after it hangs everything starts crashing, so I
suspect it's trashing memory.

> I want to get input on this from everyone, especailly from Chris and
> Steve who have put up with my breaking their frontends with my
> refactors and with whom I do not get to communicate with a great deal
> on these things.

I have no real opinion provided it doesn't break anything. :)
I can see it being mildly annoying having to build the library and
then the frontend when making/testing changes in the core, but a
script can sort that out.

> If we decide this split is a good idea I want to decide the library
> name as well. If we follow the existing netsurf support library
> convention it would be called "libns" and all exported functions would
> be prefixed with "ns_"
>
> This name fits reasonably well except it is a bit close to cocoa
> library naming where everything is prefixed with "NS" (for nextstep),
> This does not conflict (as nsurl etc. currently show) but might be
> confusing?

Doesn't affect me, ergo libns is fine :)

Chris

No comments:

Post a Comment