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

Compton and shadow for tray #223

Closed
aleksandr-samusenko opened this Issue Sep 17, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@aleksandr-samusenko

Compton draws shadow for tray, even with option "... attempts to avoid painting shadows on panels and docks" (option -C from command line) - because it gets window's hints and with this option does not make shadows for windows of type _NET_WM_WINDOW_TYPE_DOCK. This is not visible, when tray placed at bottom, but when tray placed at top or left side of screen - shadow is "slightly ugly".

"Quick fix": set tray's window hints after creating windows - in func. StartupTray (in tray.c) right after create trays's window(after "tp->window = JXCreateWindow(...)"), before check opacity - "if(settings.trayOpacity < UINT_MAX) ..." add this code:

{
Atom atomType;
Atom atomTypeToSet;

  atomType = JXInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
  atomTypeToSet = JXInternAtom(display, "_NET_WM_WINDOW_TYPE_DOCK", False);
  JXChangeProperty(display, tp->window, atomType, XA_ATOM, 32,
                   PropModeReplace,(unsigned char*)&atomTypeToSet,1);

}

"Right fix": add function in hint.c, which set type hint for all JWM's windows - trays, menus and dialog. This will make JWM "more relevant" freedesktop.org standards. BTW, JWM uses _NET_WM_WINDOW_TYPE hints for other windows, but not for own )

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing Sep 18, 2015

Owner

I agree JWM should set _NET_WM_WINDOW_TYPE on all of its windows. I think the set of windows is status windows for move/resize, menus, trays, and confirm dialogs.

JWM reads these hints, but, since JWM controls its own windows, it doesn't set the hints. Obviously that would be useful for things like compton and other pagers, etc.

Owner

joewing commented Sep 18, 2015

I agree JWM should set _NET_WM_WINDOW_TYPE on all of its windows. I think the set of windows is status windows for move/resize, menus, trays, and confirm dialogs.

JWM reads these hints, but, since JWM controls its own windows, it doesn't set the hints. Obviously that would be useful for things like compton and other pagers, etc.

@joewing joewing added the enhancement label Sep 18, 2015

@joewing joewing added this to the Version 2.3.3 milestone Sep 18, 2015

@aleksandr-samusenko

This comment has been minimized.

Show comment
Hide comment
@aleksandr-samusenko

aleksandr-samusenko Sep 18, 2015

I am afraid to write the patch - you rewrite it .... Currently, Freedesktop.org provides (http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html) the following types of windows (I have noted those that are in the JWM):

_NET_WM_WINDOW_TYPE_DESKTOP,
_NET_WM_WINDOW_TYPE_DOCK, (tray)
_NET_WM_WINDOW_TYPE_TOOLBAR,
_NET_WM_WINDOW_TYPE_MENU, (popup and tray menus)
_NET_WM_WINDOW_TYPE_UTILITY,
_NET_WM_WINDOW_TYPE_SPLASH,
_NET_WM_WINDOW_TYPE_DIALOG, (exit dialog)
_NET_WM_WINDOW_TYPE_NORMAL,

Small window with size and position - specific to JWM, for them hints are not required, I suppose.

I am afraid to write the patch - you rewrite it .... Currently, Freedesktop.org provides (http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html) the following types of windows (I have noted those that are in the JWM):

_NET_WM_WINDOW_TYPE_DESKTOP,
_NET_WM_WINDOW_TYPE_DOCK, (tray)
_NET_WM_WINDOW_TYPE_TOOLBAR,
_NET_WM_WINDOW_TYPE_MENU, (popup and tray menus)
_NET_WM_WINDOW_TYPE_UTILITY,
_NET_WM_WINDOW_TYPE_SPLASH,
_NET_WM_WINDOW_TYPE_DIALOG, (exit dialog)
_NET_WM_WINDOW_TYPE_NORMAL,

Small window with size and position - specific to JWM, for them hints are not required, I suppose.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing Sep 19, 2015

Owner

Don't be afraid to write a patch. I usually try to make things look consistent and may change stuff around if I think there's a better way to accomplish something, but I certainly don't mind doing so. I know the code pretty well (obviously) and like to keep things consistent if possible, but that shouldn't stop anyone from tinkering and submitting patches.

In any case, this is a pretty small and useful change, so I added a new "SetAtomAtom" function to hint.c and call it to set the window type after the relevant XCreateWindow calls.

Owner

joewing commented Sep 19, 2015

Don't be afraid to write a patch. I usually try to make things look consistent and may change stuff around if I think there's a better way to accomplish something, but I certainly don't mind doing so. I know the code pretty well (obviously) and like to keep things consistent if possible, but that shouldn't stop anyone from tinkering and submitting patches.

In any case, this is a pretty small and useful change, so I added a new "SetAtomAtom" function to hint.c and call it to set the window type after the relevant XCreateWindow calls.

@aleksandr-samusenko

This comment has been minimized.

Show comment
Hide comment
@aleksandr-samusenko

aleksandr-samusenko Sep 20, 2015

Mmm... Your last commit doesn't work for trays, because initialization of atoms(atomsList) occures after creation of tray(s) - maybe call StartupHints() before call any Startup() in func. Startup (in main.c)? Another "lite refactoring" suggestion: so if atoms have already initialized, may be to rewrite code with call JXInternAtom in dock.c and tray.c?

Mmm... Your last commit doesn't work for trays, because initialization of atoms(atomsList) occures after creation of tray(s) - maybe call StartupHints() before call any Startup() in func. Startup (in main.c)? Another "lite refactoring" suggestion: so if atoms have already initialized, may be to rewrite code with call JXInternAtom in dock.c and tray.c?

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing Sep 20, 2015

Owner

Thanks for catching that! It should be fixed now. I took your suggestion and rearranged things a bit so that JXInternAtom isn't needed in tray.c and only needed once in dock.c (for the property whose name is generated).

Owner

joewing commented Sep 20, 2015

Thanks for catching that! It should be fixed now. I took your suggestion and rearranged things a bit so that JXInternAtom isn't needed in tray.c and only needed once in dock.c (for the property whose name is generated).

@aleksandr-samusenko

This comment has been minimized.

Show comment
Hide comment
@aleksandr-samusenko

aleksandr-samusenko Sep 27, 2015

So, no one else did not write anything on this issue, I believe it can be closed.

So, no one else did not write anything on this issue, I believe it can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment