28 Mar
2016
28 Mar
'16
3 p.m.
(I'm not sure what is the best channel to discuss jalv.select
development other than opening a Github issue right away. If this is not
the right place, please direct to me to an appropriate mailing list.)
Currently, if I have jalv.select already running, whether minimized or
not, and try to run it again, I get the the following error:
$ jalv.select
The program 'jalv.select' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
(Details: serial 10 error_code 10 request_code 33 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
It is probably a good thing that only one runnning instance of
jalv.select is allowed, but the error message should probably be more
helpful (I guess the error has to do with registering the global
keyboard shortcut for opening the jalv.select window, which doesn't work
in all desktop environments anyway).
What I would ideally like is that, if jalv.select is already running and
you start another instance, the running instance opens its window (if
minimized). That would require some kind of IPC, so I'm not sure, if
this is something that's worth adding. As as simple hack, jalv.select
could just create a socket file at a known location, or it could use
DBus, which has the advantage that the "open jalv.select window" action
could be caleld from any generic DBus client.
But it would allow to define a keyboard shortcut to open the jalv.select
window accross different desktop environments, since you could use the
feature of your preferred desktop to bind a progranm or script to global
shortcut.
What do you think?
Chris