| Age | Commit message (Collapse) | Author |
|---|
|
click was
Bug #5152 - "mouse double-click time is too low by default - 200ms"
We only use the doubleclick in one place in the default configuration,
for doubleclicking titlebars to maximize windows, so any negative impact
of increasing the timeout should be minimal, especially with the
addition of requiring the two clicks to be in the same place.
Doubleclicks are hardcoded to occur within 8 pixels for now, it doesn't
seem worth it to add a config until someone complains. A possibility is
using the drag threshold, but some people have that set very low so it
could be hard to doubleclick then.
|
|
|
|
example: context="Top Left Right Bottom"
|
|
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.
|
|
|
|
binding/menu instead.
Also, be more careful about making the prompt buttons look pressed, don't make them pressed from a motion notify event if they didnt first handle the press.
|
|
|
|
Pressing a button and leave/enter would cause the button to show hover mode, not pressed mode. Change the behaviour back to how it used to be for pressing (the button stays pressed when you move outside of its box) and make it work correctly, as commit 041d17373e04 also did for menus.
Reverting this behaviour because it seems impossible to do the enter/leave stuff correctly for the close button on maximized windows. Leaving the titlebar contexts doesn't give us an Enter event to go along with it, so even if we check all motion events, the button will flash unpressed when leaving the topright contexts.
|
|
Conflicts:
openbox/openbox.c
openbox/session.c
|
|
|
|
|
|
Diffing against the old work branch where most of the changes
in backport were cherry-picked from indicates this should be
alright. (0de9097017d4d1991388a35e380a57dc1135b431)
|
|
|
|
an action.
Commit c907f5af4ad16b1 broke kdesktop again, so we have to fix it at an even finer level.
|
|
finer level. make a pending ReplayPointer happen before moving/showing/hiding a window in an action
|
|
Conflicts:
openbox/client.c
openbox/event.c
openbox/mouse.c
openbox/openbox.c
openbox/prop.c
openbox/prop.h
openbox/screen.c
parser/parse.c
parser/parse.h
|
|
that occurs, so it goes to the right window. if they are not, then just wait until after the actions are run (for kdesktop's sake really)
|
|
holy search and replace batman
|
|
|
|
obt_display which obt can use, and the application.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
going to work
|
|
|
|
|
|
probably crashes but its been way too long without a commit.
|
|
|
|
desktop context, so desktop stuff applies to it too.
|
|
binding for the same button AND STATE then fallback.
|
|
|
|
after the buttonpress event is run
|
|
and bottom contexts resize vertically in the default config file.
|
|
pressed is released
|
|
buttons count as clicking on the buttons
|
|
|
|
however this patch does fix the aforementioned problem.
actions need some reworking... yeah... later...
|
|
tell any difference in the events generated without it.
grab mouse buttons on the client window itself for client bindings. this fixes the weird "click and drag doesnt work when the window is focused" behavior ive been seeing with kdesktop. hooray !
|
|
is there now.
|
|
|
|
2) update copyrights.
3) make release. ok that part not quite yet.
|
|
all related to _NET_WM_USER_TIME and focus stealing prevention
a) add launcher startup notification. this means when you run something from
the openbox menu or a key/mouse binding, that startup notification will go
on in openbox and other applications like your panel or something
b) add the _NET_WM_USER_TIME property for windows
c) use the _NET_WM_USER_TIME data and startup notification to prevent focus
stealing.
d) cookie party !! ! all are invited.
e) oh yeah, and pass around timestamps for a lot more things. like, when you
run an action, send the timestamp for the event that is running the action.
this is important for startup notification. this also affects menus.
f) yes.. cookies..
would it be a good idea to disable focus stealing prevention if a window takes
too long to load? i mean.. maybe after a certain length of time, a user can't be
expected to not do anything in any other windows, but would they still want the
new application to focus then? HMM. open question i guess..
|
|
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*
|
|
|
|
|
|
!= NULL" consistantly. props to Logan again :)
|
|
|
