| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This way, it can avoid running the code that moves it to a good position
relative to a mouse that isn't there
|
|
|
|
|
|
create an Input Context for use during keyboard grabs, and use this to
translate KeyPress events properly.
make the menu respond to KeyPress events, since these are the only ones that
can be translated properly, but still execute things from KeyRelease events
|
|
handle input from the non-base group and composed input
|
|
Conflicts:
configure.ac
data/rc.xml
openbox/client.c
openbox/event.c
openbox/focus_cycle.c
openbox/focus_cycle_popup.c
openbox/openbox.c
openbox/prop.c
openbox/prop.h
openbox/screen.c
parser/parse.c
version.h.in
|
|
Conflicts:
Makefile.am
openbox/actions/focus.c
openbox/config.c
openbox/event.c
openbox/menuframe.c
|
|
|
|
When nothing in a menu is selected, go back to selecting the open submenu.
Adjust the LeaveNotify event handling to only respond when there is not a
EnterNotify coming for the same menu frame.
Change the default submenu show/hide delays.
Have the default values for submenu show/hide match the default rc.xml
|
|
|
|
This reverts commit 828c095c8b5a2df96a38faaeb8a0df504e68e70f.
|
|
Set version stuff to 3.5.0-rc1.
Copy the CHANGELOG from 3.4-working.
Rename the obt-4.0 and obrender-4.0 pkgconfig stuff to obt-3.5 and obrender-3.5
Rename the "render" directory to "obrender" so that the public headers can be
installed in <obrender/*>
|
|
Conflicts:
obt/keyboard.c
obt/keyboard.h
openbox/event.c
openbox/menuframe.c
openbox/moveresize.c
openbox/openbox.c
openbox/screen.c
|
|
This allows users to move to the submenu across other menu items (the same
as they already could across other menu items that were submenus).
This uses the same config delay for hiding submenus as it does for showing
new ones.
Based off the ideas in bug #3762.
|
|
shouldn't have.
|
|
Conflicts:
openbox/client.c
openbox/config.c
openbox/event.c
openbox/extensions.c
openbox/focus_cycle_indicator.c
openbox/focus_cycle_popup.c
openbox/menuframe.c
openbox/moveresize.c
openbox/openbox.c
openbox/screen.c
openbox/stacking.c
openbox/startupnotify.c
|
|
consistent name style
|
|
that is actually useful
|
|
first. avoid using the key binding used to show the menu to execute something inside it.
|
|
|
|
|
|
others
|
|
but this means we can't use actions in it. oh well?
can kill the desktop notifiers now too. yay for more obvious code paths.
|
|
|
|
renaming.
let you highlight disabled menu entries, they just aren't runable of course, and add the activedisabled theme element for these entries.
add the all desktops button picture to "All desktops" in the client menu
update the themes for the new element, and some changes to make things more readable-better contrast.
CLEARLOOKS-OLIVE is now DIFFERENT FROM THE 3.4 BRANCH SO DON'T RE-RUN THEMETOXML ON IT :( :(
yeah.. i think that is everything?
|
|
key binding.
change how the first menus are placed. place them like other people place menus. maybe this is good, maybe it is bad, we will see..
|
|
even in root menu and stuff
|
|
|
|
|
|
2) let separators have labels, when they have a label, then they will appear like a menu title used to
so if you want a menu title, you use a separator in the menu itself at the top
more style work may be needed
|
|
first place
|
|
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..
|
|
|
|
|
|
|
|
|
|
--help output to not include version output.
|
|
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
|
|
inside the bevel/borders of the menu items
|
|
mask icons instead of teh bullet color, and set it based on selected/disabled/normal like the text.
|
|
|
|
|
|
|
|
more menu cleanups
|
|
any more.
redo the client-menu plugin to work with the new menu api
|
|
work, on to plugins next.
|
