lua mouse event handler - lua

I'd like to create an event handler in lua which can detect and locate mouse clicks (and ideally wheel movements) within a window, but can't find any way of doing it.
Is there any way of doing it in lua, or would it be possible to create a hook somehow?
Events don't have to be reacted to immediately, so if there were some way of creating a table of mouse events which could subsequently be read from that would be fine.
I'm on ubuntu 14.04, and have Python available (if that helps). Thanks David

Not sure exactly what your requirements are, but there's a few options.
By far the easiest would be to use would be LOVE -- technically it's a sort of game framework that hosts Lua scripts but it displays a window and you can handle the events inside of the Lua runtime. Code to accomplish this would be roughly:
function love.mousepressed(x, y, button)
-- do stuff here
end
More difficult but more Lua-centric might be something like wxLua which should allow you to create and manage a native window against the wxWidgets library (N.B. I have never gotten this to compile and run on OS X)
There's a number of bindings like wxLua to other GUI frameworks. There's a complete list over at the lua-users wiki.

Related

Is it possible to customize your desktop through the electron framework?

I'm working on a project in which the user will be able to change windows app icons through an application. Is it possible to have electron perform such a task or is it impossible for the electron framework to actually communicate with windows like that?
I sadly can't proof that but
I think it is possible. You could for example use Child Process and spawn processes that do things for you or write your own c/c++ modules. You can actually write c/c++ node functions, classes and so on, wrap them and use them in nodejs. Here to the Reference. Be aware though, if you don't find any pre-made solutions you have to do that for every operating system individual!

Create interactive GTK interface through Lua

I'm building an application heavily reliant on plugins. These are coded in Lua for easier and faster development.
I now want to add GTK user interfaces for the plugin's configurations. The problem right now is that I need a way to interact with the interface through external code (signals and callbacks basically). And I'm not sure how to implement that behaviour with only an external Lua script.
Is my approach correct or should I instead implement a native solution in my framework for UI?
If you are on linux or BSD, Lua is a perfectly valid choice for GTK. Just take a look to the lua-lgi project. Once installed, you can start building an UI in a matter of seconds:
lgi = require'lgi'
Gtk = lgi.require'Gtk'
dialog = Gtk.MessageDialog { text = 'This is a text message.', buttons = 'CLOSE' }
dialog:show_all()
Gtk.main()
The greatest feature of lgi is that it works for every GObject based library, e.g. cairo, goffice, gnome-db and many more.
If you are on Windows you are out of luck. I have built a working installer but it is more a proof-of-concept than a real project. The road to that has been really tough, expecially because gobject-introspection (widely used by lgi) is not cross-platform friendly yet.
I have no experience on other OS.

Usin Griffin Powermate in Dart

I know this sounds weird, but I am making a program in Dart in browser that takes input from the Griffin Powermate USB know controller. So far, I have been using the included drivers and mapped a click on the knob to a click on the mouse. Now I have run into a problem with this: The default drivers send both "buttonDown" and "buttonUp" events at the time of release, and nothing at the time when I would expect "buttonDown"-events.
I assume I will have to ignore the drivers and dive into the details. So I have the following questions:
Is there a magical driver replacement(preferably for OSX, but I can install another OS) that fixes the problem immediately?
Is there a way to access generic USB HID devices in Dart? (like 'node-hid' for node.js)

Lua Debugger that can Attach to Process

My company has a program that uses Lua embedded in its runtime, loading up .lua files from disk and executing functions defined in them repeatedly.
Is there a way to attach to the running process and set breakpoints in my .lua files? (I'd accept either gdb-style command-line debugging as part of the Lua distribution, or perhaps a third-party IDE that provides Visual-Studio-like GUI breakpoints.)
Or is what I'm asking for entirely nonsensical and impossible given the nature of the runtime loading up random files from disk?
Edit: Looks like it's not nonsensical, given that Lua's own debug.getinfo() function can determine the source file for a given function, and debug.sethook() allows a callback for each new line of code entered. So, it's reasonable to load source code from disk and be able to tell when the interpreter is executing a particular line of code from that file. The question remains: how do I latch onto an existing process that has a Lua interpreter and inject my own trace function (which can then watch for file/line number pairs and pause execution)?
If you can modify the .lua files, you can insert the following call just before anything you need to debug:
require 'remdebug.engine'.start()
It starts the RemDebug Lua debugger engine and tries to connect to a controller. If it cannot connect, it will just continue running as normal. I did some fixes to the debugger engine, such as dealing with temporary variables, and my student is working on a debugger GUI (due next year).
In the meantime, you can try if Lua Development Tools works for you. It features a debugger similar to RemDebug, which should be possible to set up as follows:
require("debugger")(host, port, idekey)
Alternatively, you can use SciTE-debug, which is an extension to the SciTE editor, and can serve as a controller to RemDebug. Just make sure you insert the call to remdebug.engine.start somewhere in your Lua code and insert this into the SciTE output window:
:debug.target=remote.lua
When you start your program, SciTE should show the source and current line.
I've been using Decoda editor for that. It allows you to attach to a running C++ application, after that it detects that you're running a Lua Interpreter within your C++ code and show your Lua source code, where you can add beakpoints and inspect variables as usual.
This is an alternative I use after much searching. If you have an external executable that loads lua, I got this working in a few minutes. The op is very responsive, it has an interactive debugger which loads your code you can place debug points interactively. It doesn't have an editor, but I use scite or crimson editor and start the executable, one line in your main lua module enables the debugger.
http://www.cushy-code.com/grld/ - this link seems dead now
I've moved to eclipse.org/ldt it has an ide and integrated debugger, recommended
hth
The Lua plugin for IntelliJ has a working debugger with no special setup required other than pointing to your Lua interpreter.
Here's a screencast of it:
http://www.screencast.com/t/CBWIkoZPg
Similar to what Michal Kottman described, I have implemented a debugger based on RemDebug, but with additional fixes and features (on github: https://github.com/pkulchenko/MobDebug).
You can update your .lua file with require("mobdebug").start("localhost", 8171) at the point where you want the debugging to start. You can then use the command line debugger to execute commands, set breakpoints, evaluate/execute expressions and so on.
As an alternative, you can use ZeroBrane Studio IDE, which integrates with the debugger and gives you a front-end to load your code and execute same debugger commands in a nice GUI. If you want to see the IDE in action, I have a simple demo here: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style.
You should probably use Decoda.
Go to Debug -> Processes -> Attach to attach your process. This should work fine.
Well the easiest way is this, thanks to the genius author
https://github.com/slembcke/debugger.lua
you don't need to setup a remote debug server ,just require one file,and simplely call dbg() and it will pause,just like gdb
an tutorial is also shipped with it, check it out.

Using EXE's instead of DLL's as plugins - Ways to "one way, one time" transfer information

tldr; at bottom.
Ok, so once again an interesting problem and I'm looking for a fun and interesting solution.
My current project involves being very modular, meaning the program functionality will be easily changed based on different modules and the program would adapt.
So I started out with the typical route, which is using DLL plugins. Now this is just way to normal, I want to think outside the box a bit.
The modules included in my program are long running campaigns that may take weeks to finish, and there will be many running at a time. So stability is a big issue, so I thought about what Google Chrome does. Processes, not DLLs or threads.
So I have a framework going and I need a way to get some information about each module (which are now EXEs). Now for my DLL framework I was exporting a "Register" function that would fill in some information.
So I thought to myself, hey EXEs can export functions, let's see if that actually works...It doesn't. I did some research into how Windows handles theses things and I don't feel like hacking the PE headers on the fly (but it's the out of the box kind of thinking I'm going for).
I'm planning on using named pipes and CLI parameters to transfer data between the main program and the module exe's. I could use that in a register fashion, but I want to here other peoples thoughts.
tldr: I'm using EXE's instead of DLL's for plugins. Looking for a way to easily export one time information like a exported "Register" function would on a DLL. Thoughts?
You might still consider having the modules written as DLLs with defined entrypoints (e.g., the Register function). Then you write the executable that loads the specified DLL. Your main application would fire off the driver executable and give it a name of a plugin DLL.
That way it is still easy to define and export the set of APIs that must be provided yet still run it as a separate process. The one executable that you write can load the specified DLL and then handle the necessary IPC with the main app.
You could define a protocol via the stdin/stdout, named pipes, sockets, etc.
I have successfully used 'plain' COM for several projects, and objects inheriting from TAutoObject. The bonusses here are IDL; the interopability with .Net, VBA and other non-Delphi things; and the fact that implementors still can choose wether to supply a DLL, an exe, an NT-service, and optionally run hosted over the network (COM+/DCOM). There may be several considerations you should handle about multi-threading and locking, but I found all that I needed to know online.
You can, of course, not use symbols exported by a (running) exe since it is running in another boundary. But, you can load an exe as an image (as you would do with a library) using LoadLibrary(Ex) and then, use the functions exported by the exe. I have tested (just for fun) when debugging PeStudio. See the snapshot below of chrome.exe loaded in the process space of PeStudio.exe using LoadLibrary.

Resources