| Age | Commit message (Collapse) | Author |
|---|
|
interacting with another window (Fix bug 5419).
When the execute action was run, we would say that the user had used the focused
at that time. Then when a new window popped up, we'd think the user was busy in
the current window and prevent the new one from steal focus.
Now the execute action does not update the "user interacted with the focused
window" timestamp anymore. So, if they aren't currently typing in some window
when they trigger an execute action, and the window appears, it will steal
focus.
|
|
if the window is related to other existing windows
and one of those windows was the last used
then we will give it a launch time equal to the last user time,
which will end up giving the window focus probably.
else
the window is related to other windows, but you are not working in them?
seems suspicious, so we will give it a launch time of NOW - STEAL_INTERVAL,
so it will be given focus only if we didn't use something else during the
steal interval.
else
the window is all on its own, so we can't judge it. give it a launch time
equal to the last user time, so it will probably take focus.
this way running things from a terminal will give them focus, but popups
without a launch time shouldn't steal focus so easily.
|
|
(instead of 0.5 seconds)
|
|
action on the focused window
update it at the end of running actions instead of multiple times (once for
each action)
|
|
openbox
adds a function event_reset_time() that forces event_time() to look for a new (future) timestamp
|
|
This function never returns CurrentTime, which is nice, cuz using CurrentTime for XSetFocus always sucks.
If the current XEvent did not have a timestamp, then event_time() will find one. It finds the first timestamp available in the X event queue, meaning the earliest timestamp >= the current (nontimestamped) event. All future events should have a timestamp >= event_time(), so using this in XSetFocus() should not mess up any future calls we make to it.
This change seems to work well, as it appears to fix bug #3648.
|
|
pointer leaves it
This uses the same delay to unfocus as is used for focusing on enter
|
|
This reverts commit fd2f617be7ff57fcb187daa737f66d243544c8cd.
This reverts commit a47d0a53652a96ca1df96fc9268757df1431ae55.
This reverts commit a1908e076736e1a618bd305c5963dbfecaa30497.
This reverts commit dc2e6f6bf7143a56de360a393b33906735e63625.
This reverts commit 985e7dadf9a3ebf4bd265d955c3198e96405e5d2.
This reverts commit db781556d63d1a50bd1b1b4b6b5423ef703bf2c7.
This reverts commit feec8f663f0a11546c2da87575fecc8a88d97ca1.
|
|
Conflicts:
openbox/client.c
openbox/prop.c
openbox/prop.h
|
|
The code assumed the timestamps had the same domain as the type Xlib
uses for them, which is almost never the case with Xlib. Change all
involved variables to guint32.
|
|
|
|
Conflicts:
openbox/client.c
openbox/event.c
openbox/event.h
|
|
Also moves a comment from many places into one place.
|
|
shouldn't have.
|
|
|
|
|
|
|
|
also mucho fixed for <underMouse>
|
|
every key press. just ungrab the passive grab when there is no active grab and we are going to move focus.
this should be less intrusive and seems to work
|
|
causing us to not ignore the right enter events
|
|
|
|
|
|
most interesting is the change in focus_fallback, which means that it won't
call xsetinput focus in some cases, potentially reducing flicker and stuff.
also potentially producing bugs? heh.
the screen.c focus fallback code doesn't seem to need special cases anymore,
which is really good, if that is really the case.
move the focus_tried stuff out of event.c into focus.c, where it seems to
belong.
|
|
2) update copyrights.
3) make release. ok that part not quite yet.
|
|
|
|
1. some random compiling/style cleanups
2. some bigfixes
- mislogic in per-window-settings and focusing new windows
- use client_can_focus rather than checking variables for directional focus
- MAYBE fix all those lock-ups forever. using event_curtime (a new variable) now instead of event_lasttime. event_lasttime is still used however when the event being processed did not have a time associated with it. this may or may not be a problem, and will be seen.
3. um.. i forget
4. oh yeah, 3rd party docks are now treated like the internal ob dock irt focus. that is, clicking on them won't pass them focus. this is going to be ratified as expected behavior in the wm-spec just now. if docks/panels want focus they can request it with _net_active_window, and then they can have all the focus they want! one day alt-tabbing around dock windows might be nice. but not until the ob dock is moved out into a separate application. going to have to add a wmapp selection and stuff for that though... ugly. who uses wmdockapps anymore !? someone must.. *sigh*
|
|
|
|
|
|
instead of doing a focus fallback, which instantly focuses, and doesn't raise, we do an event_enter_client which simulates the act of entering the window with the pointer
|
|
|
|
enter/leave events as these are used for highlighting hover buttons and ignoring these makes the hover state out of sync sometimes
|
|
|
|
--help output to not include version output.
|
|
support reconfiguring throughout the entire codebase.
|
|
|
|
|
|
File descriptors added to the event loop.
|
|
|
|
|
|
|
|
|
|
|
