Remember me

Lost Password?

Register now!


Who's Online
84 user(s) are online (67 user(s) are browsing Forums)

Members: 2
Guests: 82

abalaban, mufa, more...

Support us!


Report message:*

Re: NetSurf issues & wishes

Subject: Re: NetSurf issues & wishes
by Chris on 2016/9/3 23:50:00


* If I edit the "Hostlist menu", the changes aren't visible in the menu until closing & restarting NetSurf. However, changes to "Hotlist toolbar" ARE applied once the Hotlist window is closed. Could something similar be done for the "Hotlist menu"?

Yes, in fact it was and I keep enabling/disabling it, but it makes it all a bit unstable. I intend to re-write the menus to use menuclass at which point dynamic updating of the hotlist menu will be easy and should be reliable.

I can't promise when I'll get round to this though, when I started work on it I got distracted and re-implemented the context menus instead.

* Highlighting (non-editable) text can be rather fiddly, at least partly due to the 'grab scrolling' feature (which I do actually like a lot). Often I fail to select the first character (too far right), or grab-scroll instead (too far left), especially when the first letter is a thin one like "l". Would it be possible to make the "selectable area" slightly wider than the text itself?

Probably not, but there is a solution. RISC OS has has an "adjust" option for selections, which allows you to add or remove to already highlighted areas. It's pretty cool, and because NetSurf started out as a RISC OS web browser the adjust functionality is implemented. If you click/drag a highlighted area using the middle mouse button, it will make it bigger/smaller. It's easy to add that missing character, and also highlighting over many screens of text is much more convenient.


Alternatively, is there a keyboard qualifier that disables grab-scrolling?

No, I don't think so.


* Is it possible that double-clicking a (non-editable) piece of text will highlight the whole word? (And possible the whole line/paragraph if you do it again?) Like happens for editable text. Would be a partial work-around for difficulties highlighting text.

This may already be on the bugtracker. If it isn't, add it.


* There seems to be some kind of crash related to opening a window from the Hostlist, and then closing that window. I'll report more info when I have it...



* In the Hotlist window, dragging & dropping individual sites onto a folder ("directory"?) puts it at the top of that folder's contents. IMHO it makes more sense to put it at the bottom, although I'll concede that Firefox has flipped & flopped on this behaviour...

Yeah, weird. Bugtracker.


* I have "Open new tabs in background" ticked, but this causes "Project/New tab" to also open in the background, which doesn't make much sense to me. If I open a new (empty) tab, it's because I want to do something straight away (like paste an address). And there is typically no "content" to load in the background, unlike a link.

Probably easy.


* "tab_new_session:1" does not bring the screen to the front, when the window is already open. This behaviour seems annoyingly inconsistent, since it does come to the front if NetSurf wasn't already running. I'm not sure whether the best solution is to (1) stop NetSurf bringing it's window/screen to the front when it is first created when opening a link (is that even possible... or desirable?), or (2) Simply always bring the window/screen to the front (when opening a link), despite "Open new tabs in background" (seems a bit strange & potentially unwanted).

Probably needs to come to the front if tab_new_session:1. That should be easy enough.


* Is it possible for double-clicking a site in the Hotlist window to obey "tab_new_session:1"? Perhaps by using ARexx to send itself a message to open that link? (I guess you'd need to open a (temporary) second ARexx port, to be able to send yourself a message... or start a "disposable" process/task to do the job.)

No, that's the whole "the hotlist doesn't know which window to open tabs in" thing. There's already a bug/feature report for that I believe.

Using ARexx doesn't make it any easier because it's triggered from the core.


* IMHO NetSurf should provide some work-around to the "Please insert volume http:" requester issue, whether that be temporarily assigning http: to RAM:, or installing your HTTP handler as part of NetSurf's installation. The latter would be better, since it'd mean such images (should) appear, but the former would be much much easier to implement (if you can't face the extra installer complexity).

I'd rather the root cause was fixed.

Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project