Hotkey Manager

[Luc The Perverse]

I have no idea how to proceed.

Here are my objectives:
1. Make a "plugin - based" hotkey manager for Java apps/classes
2. Eliminate most latency in loading frequently used Java programs

I'm not sure how to go about this - I may need to a client in C++ and have it communicate with a sister Java client - or I may need to rely heavily on JVI.

I would like to write a version for Windows and then later make one for Linux.

The idea is simple - I press a key, or set of keys, a window pops up, I use the window, and then it goes away. I want to do this as seamlessly as possible, and have the latency between pushing the keystroke and loading the window as low as possible (1/4 second is probably acceptable) This tells me I need to have the things in memory, ready to go, with my virtual machine already running.

I tried native compilation of a music search client I had made, and then mapped (using windows convoluted start menu shortcut key macro system) the program to run when CTRL + ALT + F3 was pressed. The latency was better than most things, and the app itself didn't require you wait for a dog to stop dancing, but it still needs some work - and if I could speed it up that would be great.

My problem is - I don't want "just a music search client" I want to automate a number of tasks such as real time encryption, dictionary and spell check lookups, Google searches, music list tasks. I want to unify them, and be able to save configurations (and even change configurations using a hotkey!).

It is very tedious setting up CTRL+ALT+N to load notepad using the windows method in the startmenu when it is one of about 25 frequently used windows shortcuts. It is even harder to remember.

So I want a client that takes care of all my shortcuts for me, lets me change the easily.

It could invoke things on a timer or from a hotkey, or on system boot etc.

Anyone know where I could find such a thingie? Or any ideas on the best way to make one?

 

[Luc The Perverse]

I have no idea how to proceed.

*snip*

I had no idea I posted this in HTML

How embarassing

 

[Chris Uppal]

I had no idea I posted this in HTML

How embarassing

Never mind...

Now, as to your /other/ problem (;-) I think you can assume that no reasonable
Java implementation is ever going to start up fast enough for this to work
well -- there's just too much to do before it can get any useful work done.

Also, I don't know of any way of hooking "global" keyboard events from Java
(but that might just be my ignorance).

So both considerations suggest that a good architecture would be for your Java
stuff to be a single long-lived process which (amongst other things) listened
on a socket, waiting to be told to start an "application" (which is really just
another window opened from the same program). It would probably be sufficient
to create a little program in some fast-starting language which opened a socket
connection and passed an instruction through to the "main" program then quit (I
use that architecture myself). If so then you can tell Windows to start that
program from a hot-key combination without having to mess with real Windows
programming by putting a shortcut with that hotkey somewhere in the start menu.
That leaves you with the choice of implementation language. One option would
be to use a small footprint language like C (or compiled Forth or whatever
suits your fancy); however it might be that one of the Windows scripting
languages like jscript would work just as well in practice if the DLLs needed
to interpret the script tended to be loaded into memory already (and if it's
possible to open a local socket from them -- I have no idea whether it is).

Of course, if you can find a way to hook global hot-keys from Java then there's
no need for the helper program or the socket...

-- chris

 

[Chris Uppal]

It would
probably be sufficient to create a little program in some fast-starting
language which opened a socket connection and passed an instruction
through to the "main" program then quit (I use that architecture myself).

Come to think of it, since you said you're using Jet to compile Java, the
startup overhead for a small program which just wrote to a socket would
probably be quite a bit lower than for a full-blown GUI application. So it
might be that Java+Jet /would/ be fast enough in this case -- it's worth a try
anyway unless you have another language which (for whatever reason) you'd
/prefer/ to use.

-- chris

 

[Luc The Perverse]

Come to think of it, since you said you're using Jet to compile Java, the
startup overhead for a small program which just wrote to a socket would
probably be quite a bit lower than for a full-blown GUI application. So
it
might be that Java+Jet /would/ be fast enough in this case -- it's worth a
try
anyway unless you have another language which (for whatever reason) you'd
/prefer/ to use.

No I love Java for everything except its footprint and its delayed runtime
(both of which have nothing to do with the language itself)

 

[Luc The Perverse]

Never mind...

Now, as to your /other/ problem (;-) I think you can assume that no
reasonable
Java implementation is ever going to start up fast enough for this to work
well -- there's just too much to do before it can get any useful work
done.

Also, I don't know of any way of hooking "global" keyboard events from
Java
(but that might just be my ignorance).

So both considerations suggest that a good architecture would be for your
Java
stuff to be a single long-lived process which (amongst other things)
listened
on a socket, waiting to be told to start an "application" (which is really
just
another window opened from the same program). It would probably be
sufficient
to create a little program in some fast-starting language which opened a
socket
connection and passed an instruction through to the "main" program then
quit (I
use that architecture myself). If so then you can tell Windows to start
that
program from a hot-key combination without having to mess with real
Windows
programming by putting a shortcut with that hotkey somewhere in the start
menu.
That leaves you with the choice of implementation language. One option
would
be to use a small footprint language like C (or compiled Forth or whatever
suits your fancy); however it might be that one of the Windows scripting
languages like jscript would work just as well in practice if the DLLs
needed
to interpret the script tended to be loaded into memory already (and if
it's
possible to open a local socket from them -- I have no idea whether it
is).

Of course, if you can find a way to hook global hot-keys from Java then
there's
no need for the helper program or the socket...

I don't know why I never think of Datagrams - but the solution is perfect!
It would even allow me to broaden the scope of the program to allow messages
over the network (although I suppose I would need to add verification or use
TCP if it is off the local computer). I always think I have to work with
stupid windows messages.

I have never written a networking program in any language but Java (I tried
one in C++ and eventually gave up) Oh yeah - I wrote something in VB
once - but that doesn't solve any problems I am having.

I will probably write it in C or C++ and use your idea - because you are
smart

Thank you d00d.