Hello:

That did it.
Thanks a lot.

But (for some unknown reason) still no 'selective download' feature in this version.
It's been in the FAQ for the longest time, at least 2005 and a very useful feature.

I've sent Yamamoto an e-mail asking about this.
Maybe it's an option when compiling?

Thanks a lot for your help.

Cheers,

A.

Hello:

Thanks for the info.

But I was using the package browser page: http://devuanpackages.viralds.it/ and could not find it.
Then I used SPM with the http://deb.devuan.org/merged/  ascii-backports  main contrib non-free repository checked and it did not show up either.

What am I missing?

Thanks in advance,

A.

Hello:

No idea ...
I just get the pop-up saying there's a new version available.

Didn't know that.
Thanks.

Basically, that's why I asked.

OK.
Makes sense to use the available repo.

Thanks for your input.

Cheers,

A.

Hello:

Hmm ...
No, I thought so the first two or three times.
But no, it isn't.
Besides, I had already taken my morning pill.  8^D!

Yes.
But that's exactly what is not happening.

Like I explained previously, I've been able to reproduce the conditions for this to happen.
ie: on the first site I open (first tab, no matter which site) on a freshly loaded Firefox.

That's how I have been coping with the problem.
Now I just reopen the same page on another tab and the problem is gone.
And if I do not exit Firefox, the probem will not return.

I've slammed mine on the desktop more than once.
But it has not tried to bite me (yet).

Thanks for your input.

Cheers,

A.

Hello:

I have found Leafpad to be, although usupported, really very good and lightweight.
Deserves a better fate ...

I found the solution here:

https://forum.lxde.org/viewtopic.php?t=36196#p47860

In my case, I just opened the launcher: Applications -> Accesories -> right-click on Leafpad to edit.

Changed the command line from leafpad %f to leafpad --codeset UTF-8 %f and saved.

Now, everytime I open a text file, it will save the document with the UTF-8 codeset by default.
It just happens that the hard coded default is ANSI_X3.4-1968, no bug to splat! there.    =^D 

Cheers,

A.

Hello:

No, had not thought of looking there.

To check, I opened the .xsession-errors file, took note of the last entry line number and closed it.
Then I opened FF, generated the error and reopened .xsession-errors.

These are the new lines generated:

Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
1540594962814 addons.webextension.{5657c026-efc3-4860-b43b-16e4eaa8a9aa} WARN Please specify whether you want browser_style or not in your browser_action options.
1540594962832 addons.webextension.jid1-MnnxcxisBPnSXQ@jetpack WARN Please specify whether you want browser_style or not in your browser_action options.
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".

The Xlib: lines are all over the place, I'd say over 75% of the file content is that specific line.
RANDR is disabled by the Nvidia proprietary drivers so it has a well known cause.     

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i RANDR
[    34.234] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the
[    37.011] (WW) NVIDIA(0): Not registering RandR
[    37.011] (==) RandR enabled
[    37.100] (WW) NVIDIA(1): Not registering RandR
[    37.100] (==) RandR enabled
[    37.315] (WW) NVIDIA(2): Not registering RandR
[    37.315] (==) RandR enabled
groucho@devuan:~$ 

The other new lines are of evident browser/add-on origin

addons.webextension.{5657c026-efc3-4860-b43b-16e4eaa8a9aa} WARN Please specify whether you want browser_style or not in your browser_action options.
addons.webextension.jid1-MnnxcxisBPnSXQ@jetpackn WARN Please specify whether you want browser_style or not in your browser_action options.

I have a few addons in FF:

Calomel SSL Validation
No Coin
Privacy Badger
Squared Australis Tabs
UBlock Origin
YouTube ALL HTML5
YouTube Flash Player

When I searched the web for the 5657c026-efc3-4860-b43b-16e4eaa8a9aa, I came up with a apge with this mention:

---
Name: No Coin - Block miners on the web!
Version: 0.4.14
Enabled: true
ID: {5657c026-efc3-4860-b43b-16e4eaa8a9aa}
---

So I tried disabling No Coin to see if the problem went away but no, that did not keep the problem from happening.

A search for the jid1-MnnxcxisBPnSXQ@jetpackn string did not come up with an exact match, but I found partial matches and they are all linked to the Privacy Badger add-on.

Then I tried disabling Privacy Badger to see if the problem went away but no, that did not keep the problem from happening either. 

I then, tired of all this, disabled all the addons I have installed in FF, but still no cigar.  =^/

Will have to keep looking.
But where?

Thanks a lot for your input.

Best,

A.

Hello:

Thanks for the tip, I did not know about that app.

But that's not the problem as both Devuan ASCII and X Server probe and detect the mouse properly:

groucho@devuan:~$ lsusb
Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 007 Device 004: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
--- snip ---
groucho@devuan:~$ 

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i mouse
[    38.133] (II) config/udev: Adding input device Logitech USB Optical Mouse (/dev/input/event4)
[    38.133] (**) Logitech USB Optical Mouse: Applying InputClass "evdev pointer catchall"
[    38.133] (**) Logitech USB Optical Mouse: Applying InputClass "libinput pointer catchall"
[    38.133] (II) Using input driver 'libinput' for 'Logitech USB Optical Mouse'
[    38.133] (**) Logitech USB Optical Mouse: always reports core events
[    38.192] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is tagged by udev as: Mouse
[    38.192] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is a pointer caps
[    38.224] (II) XINPUT: Adding extended input device "Logitech USB Optical Mouse" (type: MOUSE, id 10)
[    38.224] (**) Logitech USB Optical Mouse: (accel) selected scheme none/0
[    38.224] (**) Logitech USB Optical Mouse: (accel) acceleration factor: 2.000
[    38.224] (**) Logitech USB Optical Mouse: (accel) acceleration threshold: 4
[    38.284] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is tagged by udev as: Mouse
[    38.284] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is a pointer caps
[    38.284] (II) config/udev: Adding input device Logitech USB Optical Mouse (/dev/input/mouse1)
groucho@devuan:~$ 

Thanks for your input.

A.

Hello:

I seriously doubt that it's something the Debian crowd wants, just the opposite.
And as long as that Pottering fellow is at the helm, it will stay that way.

Indeed it does.

As I have made clear in other posts, I'm not a developer.
I just have 20+ years of IT work, both at home and in my profession, with a hands on approach to software and hardware save programming anything but simple batch routines.

Systemd in Linux brings back memories of my transition from W3.11 to W95, with the end of *.ini files I understood to the undocumented workings of *the registry*, which took me years to get a minimal hold of as it was constantly changing and going deeper and deeper into the OS with every iteration and as a result, the end of any chance of knowing/controlling what was going on.

The registry in Windows OSs is a virus and I see systemd as nothing more than a registry class virus infecting Linux_land.

There are people both inside and outside IT that actually want this and are quite willing to pay shitloads of money for it to happen.

Call me paranoid but I don't see this MS cozying up to Linux in various ways lately as a coincidence: these things do not happen just because or on a senior manager's whim.
What I do see (YMMV) is systemd being a sort of convergence of Linux with Windows, which will not be good for Linux and may well be its undoing.

But I also think that the options virtue of the Linux world (which has been spread far too thinly, IMO) will one day be its undoing.

Like I wrote once, elsewhere:

Sorry for the rant.

Cheers,

A.

Hello:

If you mean the Edit -> Preferences -> Behaviour -> Navigation -> Single click to activate items in Thunar, no ...
I had not thougth of that one.

I use it quite a lot, one of the first things I used to set up everytime I installed an OS, that and the type repeat settings in BIOS.

I recall (waaay back when) when it was the new thing through some special add-on software that only came with the (expensive) MS-Intellimouse.
I was delighted with that as well as with being able to go off one edge of the screen to appear at the other edge.   
So young ...

But it is only supposed to affect left button behaviour.

Now, if you mean what I do when I right-click on a link, I just do a single click, not a double click.

Let's see if the new setting makes things better and wait for the rest of the affected parties to report.

Thanks for your input.

Cheers,

A.

Hello:

Some of my best mice are PS2.   8^D

Yes!
That apparently did the trick.   =-)

I set them at:
-> Double Click Time = 425 ms
-> Double Click Distance = 5 px

It seems that if the Double Click Time is too short, it behaves like a single click, not only at the Left Button but at the Right Button also
Shouldn't work that way.

Isn't Double Click an action assigned only to the left button?
Then why would Double Click Time affect how the right button responds to input?

I think that may be where the source of the problem is.

In any case, the problem (at least for me) seems to have gone away.
As long as I don't need a shorter Double Click Time, it will be in check.

I'd appreciate it if other forum members with the same problem tried the settings I have used and see if it goes away for them too.

Thanks a lot for your input.

Best,

A.