| Age | Commit message (Collapse) | Author |
|
|
|
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 :)
|
|
|
|
|
|
|
|
|
|
individual ones
|
|
|
|
|
|
--help output to not include version output.
|
|
window. Actions bound in this context can be executed with the mouse during a move/resize on a window.
|
|
|
|
much more solid. if move/resizing a window while changing workspaces, it will follow.
|
|
can all be in the same place now woot.
allow actions to specify when they can be used (ShowMenu cant in the OB_USER_ACTION_MENU_SELECTION case)
remove KeyboardMove ad KeyboardResize. Instead, just use Move and Resize and determine if it should be a keyboard move/resize in the code
|
|
do it once on startup.
|
|
|
|
support reconfiguring throughout the entire codebase.
|
|
|
|
|
|
add the <interactive> option to them to turn off interactivity
|
|
|
|
|
|
|
|
|
|
conceptually the desktop.
|
|
split the menu into its own file.
|
|
|
|
|
|
|
|
make workspace changing a grabbed/interactive process like focus cycling is, with the popup and all.
this is some hot shit.
|