Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Programname and Windowname to logs #152

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Add Programname and Windowname to logs #152

wants to merge 12 commits into from

Conversation

t0mOURCSSn
Copy link

@t0mOURCSSn t0mOURCSSn commented Jul 28, 2016

Uploading upload.txt…

@kernc
Hi I implemented a feature to include the program & window name in logkeys' logs.
I would be honored to have my code in your project.
New to git and the whole GitHub forking aspect.
I'll gladly explain in detail the differences.
Attached you will find an example log.

The main changes are:
-added argument "--programinfo"
-the code "on key press (EV_MAKE)" was split into 2 functions, one for newlines and one to encode the scan_codes

Issues/Questions:
Currently using "xprop" to determine the window id and name, maybe there is a better command?

t0mOURCSSn and others added 7 commits July 25, 2016 18:28
Mission: Add possibility to include Program and Window name in logs
Added argument "--programinfo"
The code "on key press (EV_MAKE)" was split into 2 functions, one for newlines and one to encode the scan_codes
Added check for program change, which triggers a newline
Commented old function that required X11
Cleaned up code

 On branch windowname-no-x11
 Changes to be committed:
	modified:   src/args.cc
	modified:   src/logkeys.cc

 Untracked files:
	keymap.map
	test.log
@kernc
Copy link
Owner

kernc commented Aug 2, 2016

Thanks for this, I'd be honored to accept it. It fulfills one of the first enhancement requests, #3.

//// on processid change update program_info write '[process name] "process title" > '
//// on process title change (like firefox tabs) would be better. possibly more ressource intensive?
if (args.flags & FLAG_PROGRAMINFO) {
window_id = execute(COMMAND_STR_AWID);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This spawns three new processes on each keypress. This indeed feels somewhat intensive. Did you perhaps investigate how cumbersome the use of relevant Xlib function calls would be?

@kernc
Copy link
Owner

kernc commented Aug 2, 2016

I think there is a user's manual file somewhere in the distribution. Perhaps mention the new switch there as well?

Overall, looks good to me. @jzohrab, do you, as the previous most active maintainer, have something to add?


// active window id, title, name
#define COMMAND_STR_AWID "xprop -root 32x '\\t$0' _NET_ACTIVE_WINDOW | cut -f 2"
#define COMMAND_STR_AWTITLE "xprop -id $(" COMMAND_STR_AWID ") _NET_WM_NAME | cut -d '=' -f 2"
Copy link
Owner

@kernc kernc Aug 2, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the window title contains '=', this will include only the portion of the tile up to it. Use cut -d'=' -f2-.

@t0mOURCSSn
Copy link
Author

Hi
you raise valid points. I will look into them as soon as i have the time, that should be before the end of the week.

window_id = execute(COMMAND_STR_AWID);

if (window_id.compare(old_window_id) != 0) {
cur_process_name = execute(COMMAND_STR_AWPNAME);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

COMMAND_STR_AWPNAME contains COMMAND_STR_AWID to determine the window id.
Since here we already have the window id, it would be better to change COMMAND_STR_AWPNAME and COMMAND_STR_AWTITLE to use the already determined window_id, maybe by splitting them up?
this way we would use xprop to get the window id only once, instead of 3 times.

if (args.flags & FLAG_WINDOW_TITLE) {
window_id = execute(COMMAND_STR_AWID);

//// really ugly!
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

really ugly this part!

@kernc
Copy link
Owner

kernc commented Aug 6, 2016

Just to be safe, don't go into replacing xprop calls with Xlib calls. I now think it's better if logkeys doesn't depend on X.

@t0mOURCSSn
Copy link
Author

t0mOURCSSn commented Aug 6, 2016

I made the changes you suggested in the comments.

Apart from the 'really ugly' commented part, I think this might be the final non-X11 version. (unless we find other errors/improvements that is)
I am working on an X11 version with events.
You might want to consider adding a "milestone"/tag either before this current pull request or before the X11 version. That way we could allow for backwards-compatibility or let people download the "OG"-version.

For the X11 version:
I tried to implement X11 with XNextEvent to recieve active-window-changed events with XSelectInput(Display, Window, PropertyChangeMask) and get WM_NAME and WM_CLASS with the help of XGetWindowProperty().

While I was able to make the code snippet work in a separate while loop in main(), I was unable to make it work in the default while (read(input_fd, &event, sizeof(struct input_event)) > 0) loop.
Both XNextEvent and your while loop are listening for events.
Possible solutions I found:

  • Find an alternative to XNextEvent. There are ways to cicle for events in X11 but I can't seem to get further with X11 without expending unreasonable efforts.
  • Asynchronously multithread the X11 get-window-name function and the main while loop. The function would just bruteforce a newline with the necessary information and the main loop remains untouched. It's currently working well but I still have to figure out some minor things.

I just saw your update. How do we proceed? My code is almost finished, should we just keep it in a separate fork?

@t0mOURCSSn
Copy link
Author

FYI: I did a quick google search and it seems saving clipboard content can only be done with the help of X11.

@kernc
Copy link
Owner

kernc commented Aug 14, 2016

The problem with Xlib is that, unless it was dynamically loaded if present (dlopen & co.), it would have to be installed in order to compile / run logkeys. Which would make it somewhat less useful on headless servers where X is not used / running / desired / installed. If anything, X calls should be ifdef-ed with a compile-time flag.

Similarly to xprop, one can get clipboard contents with xclip (with X running, of course). But don't ram too much into this PR.

@@ -48,10 +48,17 @@
#define COMMAND_STR_DUMPKEYS ( EXE_DUMPKEYS " -n | " EXE_GREP " '^\\([[:space:]]shift[[:space:]]\\)*\\([[:space:]]altgr[[:space:]]\\)*keycode'" )
#define COMMAND_STR_GET_PID ( (std::string(EXE_PS " ax | " EXE_GREP " '") + program_invocation_name + "' | " EXE_GREP " -v grep").c_str() )

#define COMMAND_STR_DEVICE EXE_GREP " -E 'Handlers|EV' /proc/bus/input/devices | " EXE_GREP " -B1 120013 | " EXE_GREP " -Eo event[0-9]+"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-B1 120013 is not equal to what was here before?

…ly interested in "visible" key presses. changed printf into snprintf. updated manual file to include --window-title. #defined commands that were left in code previously.
@t0mOURCSSn
Copy link
Author

Is there still interest in this feature?
I have no idea on exactly how to use ifdef in order to find out if x is installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants