Re: history and hotlist not saved; CSS site

[Nick Roberts]

In message <5ea82c6b-73ca-6728-a118-e7111d094...@codethink.co.uk>
   Michael Drake  wrote:

> 
> On 28/04/17 11:18, Michael Drake wrote:
> >
> > We could change it not to save the hotlist on exit when
> > an external hotlist manager is used, since that would
> > be a simple change.
> 
> Done.

You are a star 8-)

I'll get to tweaking BookMaker so it no longer blocks save if NetSurf
is running.


-- 
Nick Roberts   tigger @ orpheusinternet.co.uk   

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

Re: history and hotlist not saved; CSS site

[Michael Drake]

On 28/04/17 11:18, Michael Drake wrote:


We could change it not to save the hotlist on exit when
an external hotlist manager is used, since that would
be a simple change.


Done.

Re: history and hotlist not saved; CSS site

[Michael Drake]

On 28/04/17 10:51, Michael Drake wrote:


In any case, I can make it more robust by consulting the
external hotlist option before removing from the hotlist.


Actually it already does that, so NetSurf shouldn't be saving
the hotlist when the hotlist is edited, when configured to
use an external hotlist manager, however, it will still
save the hotlist on exit.

We could change it not to save the hotlist on exit when
an external hotlist manager is used, since that would
be a simple change.

Adding support for querying the external hotlist about
whether it has a URL and removing URLs from external
requires more work, and would need a RISC OS developer.

If there are any developers interested in working on the
RISC OS front end, they would be most welcome.  None of
NetSurf's core developers use RISC OS, so we have trouble
maintaining and supporting it.

Cheers,

Re: history and hotlist not saved; CSS site

[Michael Drake]

On 27/04/17 18:03, Michael Drake wrote:


On 26/04/17 18:30, Nick Roberts wrote:


Can you just confirm that NetSurf doesn't save the file if there is an
external hotlist manager?


I don't know, off the top of my head.  I'm unfamiliar with the
external hotlist option.  If I have time tomorrow I could have
a look at the code.


As far as I can tell there are three differences in behavior when
the RISC OS front end's external hotlist option is enabled:

1. Opening the hotlist will Filer_Run the external application,
   rather than opening the NetSurf hotlist manager window.

2. The hotlist_has_url test always returns false for external
   hotlists.  (Meaning the star in the URL bar will always be
   an empty outline, rather than filled yellow, even when the
   current page is in the external hotlist.)

3. When adding pages to the hotlist, NetSurf's core hotlist code
   isn't informed.  This means that the NetSurf won't save the
   file when adding URLs.

So NetSurf won't save the hotlist file when adding pages, and
set to use an external hotlist manager.

It looks like the RISC OS front end code for removing pages
from the hotlist first checks whether the core hotlist has
the page, and if it does, it instructs the NetSurf core
hotlist to remove it, rather than the external application.

The remove from hotlist handling has no code to tell an
external hotlist to remove pages.

This means that if this code is called, and the the core
hotlist had the URL, it will remove it, which will cause
NetSurf to save the hotlist file.

I can't remember exactly how the RISC OS UI presents the
interface for removing pages from the hotlist.  It might have
been select clicking on a filled URL bar star, or adjust
clicking on a URL bar star, or something else.  If the former,
then because of point 2 above, it would not let the remove
page code get called in the first place, so the file wouldn't
get saved.

In any case, I can make it more robust by consulting the
external hotlist option before removing from the hotlist.

Cheers,