debug-ito / numpaar

NUMber Pad As A Remote

Numpaar: NUMber Pad As A Remote

Numpaar is a program that turns your (possibly wireless) number pad into a remote that controls your computer. You can think of it as just another keyboard shortcut program, but it's more powerful and extensible than traditional ones.

This is still a Beta version... Interfaces may be changed in the future.

FEATURES

• Runs on Linux with X Window System
  • (Tested under Ubuntu Linux)
• Bind any key on a number pad to any script written in Perl.
• Automatically change key bindings according to the active window.
• Stateful key bindings.
• Object-oriented key binding customization (based on Perl modules).

PREREQUISITES

• xdotool and libxdo (version 2)
  • http://www.semicomplete.com/projects/xdotool/
  • The latest version is recommended.
  • Requires libxtst to build it.
• libx11 (Xlib)
• Perl environment
  • Class::Inspector module (provided as libclass-inspector-perl package for Ubuntu)
  • Gtk2 module
  • Pango module

INSTALL

1. Place the source tree somewhere, say /opt/numpaar/

2. Build

    $ cd /opt/numpaar
    $ make
   

3. Set PATH and PERL5LIB to /opt/numpaar and /opt/numpaar/lib, respectively. For example,

    $ echo 'export PATH="/opt/numpaar:$PATH"' >> ~/.profile
    $ echo 'export PERL5LIB="/opt/numpaar/lib:$PERL5LIB"' >> ~/.profile
   

4. Create configuration file '.numpaar' in your home directory.

    $ cp /opt/numpaar/dot.numpaar.sample ~/.numpaar
   

5. Edit ~/.numpaar as you like.

HOW TO USE

Simply execute numpaar.

$ numpaar

If you already run numpaar, it is killed.

You can find more detailed document at Numpaar Wiki.

TODO

• Internationalization.
• Write document on how to configure Numpaar.
• Automate installation process.

AUTHOR

Toshio Ito

• https://github.com/debug-ito
• debug.ito [at] gmail.com

numpaar's Issues

WID of the currently active window should be available from Engines

WID is the most reliable way to select a window by xdotool etc., so it should be available from Engines.
numpaar_x must include WID in the notification string to numpaar_engine

Add heap interface to Engine

Engine is currently nothing but a blessed hash reference, so it is possible for any user-defined subclass to store its data in this hash.
However, it would be a lot nicer to provide dedicated "heap" object for data storage no matter how the implementation of Engine will be changed in the future.

Engine::getWindowTItle is misleading

The method name "Engine::getWindowTitle" is VERY misleading. Make it getWindowDescription or something.

Also in other part of source code "window title" is often used for what is called "window description" in the tutorial.
This should be fixed as well.

Refactor Engine::handler_divide, create comWinListForPager

In Engine::handler_divide window list is obtained, but this should be refactored.
Probably making Connection::comWinListForPager method or something is desirable.

Check type and string content of argument to Engine::setState

State string must be able to be included in subroutine names, so the argument to Engine::setState must be checked about its validity.

Reconsider interfaces and implementation of VideoPlayer

Numpaar::Engine::DebugIto::VideoPlayer directly deals with Engine object hash.
Use heap instead.

In addition, the interfaces it provides are too explicit.

Numpaar::Visgrep should be an independent object

Currently Numpaar::Visgrep is used as a super class of Engines, but it's not necessary at all.
It should be an independent object, and Engines that want to use it should construct and store it in the Engine's heap.

interface Numpaar::Visgrep::clickFromBase is ugly

Taking into account that there will be more comMouse* interfaces, it is better to provide "toAbsolute" or something,
which converts the Visgrep coordinates into the absolute screen coordinates.

Suggestion on Connection::comMouse** interfaces

In numpaar_x protocol, "mouseclick" operation comes with button number argument.
How about button number 0 meaning moving the pointer WITHOUT clicking?
This makes it easy to implement comMouseMove API in Connection object.

Also, comMouseLeftClick, comMouseRightClick, comMouseMiddleClick comMouseScrollUp comMouseScrollDown
might be useful, because most people (including me) do not remember what button number corresponds to each of these functions.
(is it consistent throughout various X Window configurations??)

comKeyDown and comKeyUp interfaces should accept multiple key_strings

Because comKeyString accepts multiple key strings, so should comKeyDown and comKeyUp be.

In addition, these interfaces must be tested, of course.