| here's my config for Fvwm/xmms2:
| DestroyFunc Xmms2
| AddToFunc Xmms2
| + I Exec exec xmms2-launcher
| + I Exec exec xmms2 playlist shuffle
| + I Exec exec xmms2 playlist play
| + I Silent Key KP_Right A S Exec xmms2 server volume +2
| + I Silent Key KP_Left A S Exec xmms2 server volume -2
| + I Silent Mouse 4 A S Exec xmms2 server volume +2
| + I Silent Mouse 5 A S Exec xmms2 server volume -2
| + I Silent Key Pause A C Exec xmms2 toggle
It never ceases to amaze me that Linux people
will think it's impressive to say things like: "Hey, I
can do that with 27 lines in a console window. You
poor Windoze people have to click a button or
something." Since 1995, few people will be impressed
that you can control a music player without using a
UI of any kind. They'll be even less impressed that they
can write excessively bloated and abstruse config entries
for custom commands. You may find it hard to believe,
but that just isn't a compelling salespitch.
(Not to mention the only-geeks-could-love-it naming
traditions. Anything named Fvwm/xmms2 has no right
to exist. :)
| It's just as simple to tell the WM to select a window
| and generate synthetic keystrokes if the player doesn't
| already have a command interface.
| Of course selecting a window with the WM will make the
| window active, you'll have to first capture the active
| window and switch back.
Yes. The whole point was to send messages to windows
that are not active, without changing the active window.
He doesn't have any problems with sending his commands,
as I read it. He just wants to send them to a non-active
window. I don't know of any way to do that, and if you
could it would require both a specific OS functionality and
a target process that's designed to listen somehow. The
system sends input to the active window. So it seems
the target process would need to be hooking into all input,
like a sort of super keylogger, since its window is not receiving
the input. The target software would have to be designed
for that purpose in the first place and would have to provide
config options for it. Once that's solved, you'd need to figure
out how *not* to send the specific input to the active window.
That would mean having something like a Control Panel applet
that lets you configure details of which processes can receive
input from which devices. (Or on Linux, of course, it would
require that someone online has posted 53 lines of interminable
gobbledygook that you can enter into a console window to
accomplish the same thing.)
Maybe all of that exists and is possible on your Linux
Miracle, but I don't see how. ...But at least you don't have
to use a chisel and a stone tablet, so I guess Linux may
not be far, now, from being ready for prime time. :)
On Sunday, May 18, 2014 9:03:21 AM UTC-4, Mayayana wrote:
Yes, his reply covers the issue of it being "trivial" to do in
Linux. I mean, if they want to bash Windows, at least be honest.
In the context of the thread here, "trivial" to me would mean
that the typical home computer user could easily do it. It might
be "trivial" to someone experienced in customizing Linux, but
what he posted sure isn't going to be trivial to
the vast majority of home PC users. I'm sure you can do all
kinds of cool things in Linux, but that doesn't make those things
trivial to the typical home PC user. When you post stuff like that,
it just reduces your credibility.
On Sunday, May 18, 2014 8:29:52 AM UTC-5, trader_4 wrote:
4, nothing like pointlessly enter the conversation of people who know what they're talking about and rehashing what's been said for your greater glory! Maybe some of their smarts will rub-off...you can only hope!
On Sunday, May 18, 2014 3:52:21 PM UTC-4, Bob_Villa wrote:
People who know what they're talking about would obviously
exclude you, dirt bag. Is that you're new purpose in life?
To follow me around and make snide remarks. The fact that you
had nothing relevant to say about the discussion speaks for itself.
On Sunday, May 18, 2014 8:21:17 PM UTC-4, Bob_Villa wrote:
Good that you accept that you have nothing to add to the newsgroup.
I and I'm sure many other's have noticed it for some time now. Now
you can just work on the anger management and jealousy for those that do.
On Monday, May 19, 2014 11:23:33 AM UTC-4, Bob_Villa wrote:
Since you admit you don't know anything about the topic
then obviously you're in no position to comment on what I can add.
I simply supported Mayayana's position that to attack Windows and claim
that the solution is trivial in Linux, is BS. I said the same thing M did,
that what was posted might be trivial to someone who customizes Linux,
a system administrator, a developer, etc,
but it's not trivial to a typical home PC user. M said the same thing, yet
you choose to just attack me. You really do need some anger management help.
On Tuesday, May 20, 2014 2:52:10 PM UTC-5, trader_4 wrote:
You're fair game because you have no credentials in what is being discussed
and only think you might look good by rubbing elbows with someone that doe
s know something about the subject. How can you agree with something withou
t the research to back it up? And besides...you're a dick! (or is that a co
On Tuesday, May 20, 2014 7:43:40 PM UTC-4, Bob_Villa wrote:
You obviously have no way of knowing what my credentials are.
and only think you might look good by rubbing elbows with someone that does
know something about the subject. How can you agree with something without
the research to back it up? And besides...you're a dick! (or is that a com
OK, you want to talk about my credentials? You want to talk about referenc
You want to talk about making comments in threads where you don't know anyt
hing? Let's take a trip down memory lane, where all your hostility apparen
There was a thread about installing a whole house surge protector. The
adults had it under control, whereupon you posted this gem:
"Whole house surge protection is pointless and costly...protect the individ
ual items that need it at each point of use. .02 "
Since you want references, the above link is provided to document what you
Oren asked what that comment was based on, and you replied:
"Since runs of different surge loads possibly share the same conduit or are
run side by side...surge will be induced after the protection. Leaving the
expensive device impotent."
I politely explained to you how that is wrong, to which you replied:
"This sounds like a sales pitch...there is virtually nothing that will prev
ent damage from a nearby lightning strike. Mainly because it will "jump" ov
er, or burn-out any device. Again, this is my .02"
After that, Bud and I took you apart, limb by limb. I'm an electrical engi
Bud is too. We gave you references to surge protection guides written by
committees of experts at NIST and the IEEE:
They say you're wrong. And instead of learning, this was your reply:
"Okay, okay...this will be my last two-cents on this...you can show me all
kinds of specs and recommendations, and say how "in theory" these work (and
they will work in a very specific and narrow window of lightning surge). B
ut the "real world" data is not there...it is anecdotal at best because eve
ry situation is different. "
So, the situation here is clear. It's *you* who enters threads where
you know nothing, even freely admitting it with the "just my two cents".
Then when Bud and I point out the sound science based on physics and backed
up by 75+ years of real world deployment, instead of reading and learning,
just dismiss it and call it anecdotal. Are you so stupid that you don't
realize that surges and how to protect from them has been of vital importan
for most of the last century? Phone companies, power companies, cable
companies, communications facilities, factories, etc have been involved
with surge protection, studying the best methods etc. That is reflected
in the NIST and IEEE guides we cited for you. But, heh, let's just
chuck all that out and go with your 2 cents.
And even worse, you've developed a need to follow me around and make snide
comments. So, it's my duty to expose your true ignorance and how it's
*you* who enters threads that even you freely admit you know nothing
about and start spouting BS. Even worse, it's clearly demonstrated that
you refuse to read and learn.
| Uh huh.
| When faced with answers to all your snipping it's time to
| resort to gobbledgook and ridicule.
All my snipping? You started this, remember?
You were the one who said Linux is better than
Windows and that what the OP wants to do is "trivial".
No one was attacking you. You were criticizing Windows.
All I asked was for a simple explanation of how Linux
could do what's requested. I don't think it's possible to
do. You seem to be claiming otherwise. Isn't it a fair
question to ask exactly how you can solve the OP's
| I suspected I should not have wasted my time.
| I could delve deeper but there's no point.
No need to delve deeper. It was a simple question.
The OP wanted to send secondary keyboard messages
to a non-active process without them going to the
active process. Did you understand that? Either you
know how to do that or you don't. You're posting links
about changing the default language and talking about
the flexibility of your command line music player. Those
have nothing to do with the question.
On Sunday, May 18, 2014 10:26:34 AM UTC-4, Mayayana wrote:
+1, especially about the "trivial" part in the context of
the thread here. What he posted isn't trivial to the vast
majority of home PC users and as you say, it doesn't solve
the problem asked, even for Linux.
I think his question is better summarized as he wants the ability
to tie a keyboard to a given app. Whether the app is active/inactive
wouldn't seem to matter.
Did you understand that? Either you
| > | DestroyFunc Xmms2
| > | AddToFunc Xmms2
| > | + I Exec exec xmms2-launcher
| > | + I Exec exec xmms2 playlist shuffle
| > | + I Exec exec xmms2 playlist play
| > | + I Silent Key KP_Right A S Exec xmms2 server volume +2
| > | + I Silent Key KP_Left A S Exec xmms2 server volume -2
| > | + I Silent Mouse 4 A S Exec xmms2 server volume +2
| > | + I Silent Mouse 5 A S Exec xmms2 server volume -2
| > | + I Silent Key Pause A C Exec xmms2 toggle
| > |
I can't resist rubbing it in just a little bit,
don'tcha know..... You really should try using
Windows. We have Space Age music players
that can be controlled with nothing more than
the mouse. No config files. No console window.
No muss. No fuss. No kidding. Even the volume
can be changed without a config file. It's the
very definition of "trivial". Windows is so modern
that I've been on all morning and haven't needed
to use the keyboard for anything but typing
characters. I feel like I'm living in the 21st
On 5/15/2014 3:06 PM, firstname.lastname@example.org wrote:
Look into "hotkeys", a way to control programs on your Windows computer.
There are numerous methods and applications to create hotkeys.
There are also "macrow" shortcuts and software for controlling your Win
| > The OP wanted to send secondary keyboard messages
| > to a non-active process without them going to the
| > active process.
| I think his question is better summarized as he wants the ability
| to tie a keyboard to a given app. Whether the app is active/inactive
| wouldn't seem to matter.
The basic design is that the OS gets the hardware input
and sends it to the active window. It all happens via system
messages. There's no option to tie input to a specific program
or process, as far as I know. Software alone doesn't know
what's happening at hardware level. So if the target program
is not active that does matter. It can't receive the input.
The target program would have to be listening to all input
(a systemwide "hook", like a keystroke logger uses, that arranges
to have the OS pass each message through the target program)
and it would have to somehow recognize which input is the
relevant input. Then it would also have to somehow "eat" that
input, so that the active window doesn't get the keystrokes.
I'm not aware of any such functionality. It would be very
complicated and intrusive functionality to add to any program,
which would rarely if ever be useful. (I still don't understand
why the OP needs it.)
On Sunday, May 18, 2014 11:51:36 AM UTC-4, Mayayana wrote:
For the keyboard, I agree that's true. Actually, I think we need to
back up a bit. I said keyboard, gfre said numeric keypad. I was
thinking numeric keypad on the keyboard, which I morphed into keyboard.
Actually you can get separate numeric keypads. IDK how Windows handles
a totally separate keypad at all. But certainly some apps that run under
Windows can get hardware input while not the active window. gfre
can clarify if it is a separate keypad?
It all happens via system
But it still simplifies down to tying the keypad to a certain
app or apps, while the mouse and (i think keyboard) is still tied to
other apps. When it comes down to doing the tying, what he wants
is the keyboard associated with the MP3 player.
IDK what target program you're referring to. This appears to me
to be an issue between the device driver for the keypad and the
rest of the OS and/or the app. I don't see any need for monitoring
all input. The OS only needs to know that the keypad input goes
to the MP3 player.
IDK what you mean. He pushes "3" on the keypad. That triggers
an interupt, the device driver receives the "3". Somewhere at
a higher layer in the OS, the OS knows that the keypad is
associated with the MP3 player. It gets the "3" from the device
driver and it passes the "3" to that app.
That's how it works now, no? Except that the OS passes it to
the active window.
Then it would also have to somehow "eat" that
If it's a separate keypad, then I think it may be easier, but I
tend to doubt it's doable without some effort with someone with
the right knowledge, if it's doable at all.
I authored (in C#) a Windows software that controls a piece of $800,000 lab equipment through a USB port.
This program sends instructions to the machine, the machine performs the task and then returns the result.
Based on the returned result, the app sends additional processing instructions or terminates the process.
All of this executes flawlessly in the background while I play Freecell. ;-)
FWIW, I put a lot of effort into this program. My boss just yawned. Fuck 'em!
I have not tried it yet but one of the guys over on the XP group
suggested a hot key program that might let me do a lot of the things I
want to do without actually taking the focus off of the music player
OK the simplest way to put this.
I am running an MP3 player with the playlist screen on monitor 1
(operated by several separate input devices) and I have weather RADAR
running on monitor 2. If I want to move the center of the RADAR
display, I take the focus away from the player. If I do not remember
to put it back, the input devices, scattered around the pool deck,
stop working. You might not even notice it until you are in the pool
and hit the floating "next" button to skip something you might not
want to hear right then.
I used to have 2 PCs running and this was not an issue. When I
consolidated it to one, this became an issue.
The "next" button is actually a keyboard function on the PS/2 KBD port
that also integrates the 3W1 wallbox and a separate wired numeric pad
If I could just lock the PS/2 port to a window, 90% of my problem is
I was hoping it was simply a poorly documented set up option but that
does not seem to be true.
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.