On 21 Feb, Martin Bazley wrote in message
<e21724a951.mar...@blueyonder.co.uk>:
> Firstly, congratulations and many thanks to Steve Fryatt fo his sterling
> work on the RISC OS toolbar implementation. While, as mentioned on the
> wiki, user-facing improvements aren't much in evidence, I understand the
> new implementation is much more future-proof than the old and should go
> some way towards ensuring a RISC OS port for some time to come. For
> people like me who subscribe to the commits mailing list, the amount of
> new code in the diffs for branches/stevef is positively horrifying!
Thanks! If I'd realised exactly what was involved, or that it would take me
from the day after Boxing Day until late February to complete, I suspect
that I might not have started it at all... :-)
> I'm not putting this in a bug report because I'm not quite sure if it's
> intentional or not, or if I've missed something obvious.
>
> Clicking Menu above a toolbar produces two options: a submenu and an edit
> function. The edit function, thus far, has worked exactly as I'd expect
> it to; the submenu to remove the address bar, buttons or throbber has not.
>
> It seems that the settings are not stored anywhere, and apply only to the
> window they are set in, and to its descendants (links opened in new
> windows from that one). They do not apply to windows opened by other
> means (e.g. from the hotlist or 'Open URL' dialogue). Any window not a
> descendant of the original window gets the default complement of all three
> components. In effect, the settings are lost the moment the last
> descendant of the original window is closed.
Isn't that how it always used to work? You need to set the toolbar, then
click Menu over the window and do "Display->Save as default". Having just
fired up a version from last summer, that's how it seems to have been before
(and I can't immediately see any code in 2.6 that would have behaved
differently).
> Buttons added or removed from the toolbar, on the other hand, apply to all
> windows opened as descendants of the original one and to new top-level
> windows, but not to other currently open windows or their descendants.
> I'd propose that the addition and removal of sections also works this way,
> if that was not the intention.
Logically, it ought to work the other way around: button edits don't stick
either unless you do a "Save as default". Except that treeview windows
don't have such an option, and IIRC it *is* immediate on those.
Any chance you could stick this on the bug or feature tracker? I'll need to
think through how the UI should work for this, and then sort out how to make
it happen.
> While I'm at it, a minor glitch I noticed while testing: positioning the
> mouse pointer over any toolbar and moving the scroll wheel upwards (not
> downwards) will cause the components to scroll off the bottom, for a
> seemingly infinite distance. I'm pretty sure that's not intentional.
No, that's definitely a bug. :-)
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
