re: disable mouse sort order?
- From: "Joe(theWordy)Philbrook" <jtwdyp ttlc net>
- To: Mc gnome org
- Subject: re: disable mouse sort order?
- Date: Tue, 1 May 2012 13:42:31 -0400 (EDT)
It would appear that on Apr 30, Paul Westell did say:
I haven't time to keep up with personally compiled applications. But am
totally dependent on whatever version of mc I can get from the {insert
currently booted distro here}
You might be able to get away with adding a single file to 'upgrade' mc. If
you compile --with-ncurses (not slang), and --without-gpm (or however they are
phrased).
I do see problems if you build on a system which uses libs (glibc, ncurses,
gtk+, &c.), or a kernel that are too recent. I think, older is better for
compatability. In any case, just one file each for 32 and 64 bit systems.
Yeah... Well since my personal user environment always requires more
pointy-clicky configuring {gawd do I wish the E17 devs liked human editable
config files...} of so many things which for me the default settings of any
DE or WM I ever tried make my teeth itch, {especially the keyboard shortcuts
of which I always have to change every single one...} So just about every
single one of the Linux that I install use a rolling release model that
minimizes how often I need to reconfigure my user environment from
scratch... And rolling release models tend to depend on recent kernels...
But I'm curious, Why do you dislike the -d option? So far I've not had any
problem with it (when I remember to use it that is. And I like the fact
that when I do bother wrestling my trackballs pointer over to some text I
want to copy/paste with gpm, I don't have to remember to also hold the
shift key down. (used to be that when I opened a selected file via:
vim <alt>+<enter> <enter>
Then even though I was running inside an mc session without having disabled
mouse support, I didn't need to hold the shift key to use gpm's clipboard
to copy text to from another window... But lately having to hold the shift
key even inside a subprocess, is why I've started to bother with -d...
Imagine, '<shift>+<mousebutton>'. Will wonders never cease? I have always
used '<ctl>+<mousebutton>', which then waits for you to confirm with
'<enter>', and looses all line-feeds, tabs, and probably other formatting as
well in the process.
Either way, I'd rather not have to hold either keyboard key down while holding a mouse button down with one
hand and trying to roll the trackball accurately with the other hand... Now If I could select using keyboard
shortcuts that enabled
vim-like -- VISUAL --, -- VISUAL LINE --, & -- VISUAL BLOCK --, selection
methods, preferably with a way to name the same buffer {for both copy & paste
operations} that a typical gui app in another window uses for it's ^C, ^X, &
^V shortcuts, instead of having to use ANY KIND of pointing device to mark the
text with, I'd be ecstatic. Just like I would be if all those gui apps always
pasted text to the current text cursor position without automatically moving it
to where ever the %#$@&ing rodent happens to be pointing...
In any case, 99% of the time I don't have any desire to have more mouse support
in any terminal/console application than is provided for by the terminal
program and/or console itself. So unless I recompile {a task at which I
definitely vacuum...}, my best bet for mc is -d.
My experience has been that under constant use (with CLI not GUI), 'mc -d'
will sooner or later; crash, hang, lockup, or otherwise make 'killall mc' a
desirable option. Compiling without gpm support solved this. They may have
fixed this brokenness, ... or not, but it's too late for me either way.
Well I haven't had mc aliased to "mc -d" for very long... For the sake of
anyone who hasn't yet made up their mind about -d, I'll update this thread
the first time "mc -d" makes me "kill" it's process.
In part because of my difficulty with rodent's I use a trackball... And it
doesn't happen to have a wheel button. (And if it did I'd want to disable
it) I've found that an accidental brush of a working mouse wheel ...
I understand. My mechanical KVM requires a ps2 device imnterface, which now
means special order or second-hand. I keep my soldering gun handy.
I too prefer a track-ball, but since my 'Logitech Track-Man' blew up I have
found nothing even remotely useable. I have trouble with the limited lateral
range of current track-balls (somewhere under one's thumb), where the ball of
the 'Track-Man' was controlled by my palm.
yeah, I had once an old klunky looking box like track ball with it's
buttons positioned so that I could hold my hand relatively still by resting
it's weight on my thumb which could {at my option} be sitting on either the
left button OR the flat {non-button} surface beside it, while I carefully
used my finger(s) and/or palm to gently and precisely maneuver the ball. But
it wore out years ago and very few retail stores (where I can see how it fits
my hand before I spend my very limited resources on it) carry ANY track balls
at all. I found one with a full sized ball a few years back. And since it used
optical technology to scan the balls motion rather than the 3 little rollers
that used to stick and slip with the old design, I bought it. Even though it's
"ergonomically" curved shape makes it impossible for me to use my thumb to
stabilize my hands position, and it's buttons are positioned on the curved
side so that in order to "hold" a button down long enough to mark anything
that double and or triple clicking won't do, I had to glue the dang thing down
so that I could push sideways firmly enough for the durned button to stay
"down" with one hand while I try to accurately move the pointer with my other
hand... {ever watch a two year old try to color "INSIDE" the lines of a 10
year old's coloring book???}
But at least it's a full sized ball that is detected as accurately as I can
move it... I'm afraid I can't remember the brand/model name of this ps/2
device anymore. and I'm unwilling to disturb the glue to read the label on
the bottom.
I'm just glad that I "CAN" usually manipulate the mouse well enough to get
by, And that I CAN see well enough to see what I'm marking. So what if it
sometimes takes three tries to get it right. But I'd hate to have to work with
today's gui environment if I had any "real" impairments.
--
| --- ___
| <0> <-> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| ~\___/~ <<jtwdyp ttlc net>>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]