Question about dock and clip (xrandr)
Hi,
I am testing wmaker xrandr support with the laptop's external display.
The dock is attached to the screen right edge, then, when I change my display,
the dock moves rigth. With the clip is different, the clip continues in the
same position.
The appicons are like the dock, they are attached to and screen edge, then they
work fine with xrandr.
What do you think about the idea of the set clip in one of the four corners?
Then, the clip will work with xrandr too.
OTOH, these lines at event.c:305
---8<--
case ConfigureNotify:
if (event->xconfigure.window == DefaultRootWindow(dpy)) {
#ifdef HAVE_XRANDR
XRRUpdateConfiguration(event);
#endif
}
break;
---8<--
IMO should be:
---8<--
case ConfigureNotify:
#ifdef HAVE_XRANDR
if (event->xconfigure.window == DefaultRootWindow(dpy))
XRRUpdateConfiguration(event);
#endif
break;
---8<--
And finally, someone knows whats happends when "XRRUpdateConfiguration" is
called? What function/event is called in wmaker?
Cheers,
kix
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about dock and clip (xrandr)
On Sun, 6 Jan 2013, Rodolfo García Peñas wrote: What do you think about the idea of the set clip in one of the four corners? Then, the clip will work with xrandr too. Do you mean that the clip could only be placed in one of the four corners and nowhere else? Then I don't think it's a good idea. Unless maybe if the clip could also be docked like any other appicon. To see why, here's a screenshot of my dock and clip: http://goliat.eik.bme.hu/~balaton/wmaker/OS42-WindowMaker_Screenshot.png (As a curiosity and for comparison I also included a window with OPENSTEP 4.2 running under QEMU.) I use the clip as a desktop specific dock extension so it's not tied to one of the corners. Maybe a solutions that could work is to store the clip position with relative coordinates, that is upper left: +0,+0 upper right: +0,-0 lower right: -0,-0 so always measure to the closest edge and store that instead of absolute position. IMO should be: ---8<-- case ConfigureNotify: #ifdef HAVE_XRANDR if (event->xconfigure.window == DefaultRootWindow(dpy)) XRRUpdateConfiguration(event); #endif break; ---8<-- Then why not even: #ifdef HAVE_XRANDR case ConfigureNotify: if (event->xconfigure.window == DefaultRootWindow(dpy)) XRRUpdateConfiguration(event); break; #endif And finally, someone knows whats happends when "XRRUpdateConfiguration" is called? What function/event is called in wmaker? Don't know anything about this but the man page says it is a callback to notify the xlib client side about changes in the screen configuration which is not done automatically to let clients decide when's the best time to call this. So no event is generated in wmaker but wmaker should call this if it gets an "RRScreenChangeNotify, or ConfigureNotify (on the root window)" according to the docs. Regards, BALATON Zoltan
Re: Question about dock and clip (xrandr)
On 06/01/2013 16:12, BALATON Zoltan wrote: > On Sun, 6 Jan 2013, Rodolfo García Peñas wrote: >> What do you think about the idea of the set clip in one of the four >> corners? Then, the clip will work with xrandr too. > > Do you mean that the clip could only be placed in one of the four > corners and nowhere else? Then I don't think it's a good idea. Unless > maybe if the clip could also be docked like any other appicon. To see > why, here's a screenshot of my dock and clip: > http://goliat.eik.bme.hu/~balaton/wmaker/OS42-WindowMaker_Screenshot.png Good example :-) > (As a curiosity and for comparison I also included a window with > OPENSTEP 4.2 running under QEMU.) I use the clip as a desktop specific > dock extension so it's not tied to one of the corners. Maybe a solutions > that could work is to store the clip position with relative coordinates, > that is upper left: +0,+0 upper right: +0,-0 lower right: -0,-0 so > always measure to the closest edge and store that instead of absolute > position. Yes, probably the option is check the screen size (p.e. 1024x768), then cut the screen in 4 areas: 1. (up-left)0x0 to (1024/2)x(768/2) 2. (up-right) (1024/2)x0 to 1024x(768/2) 3. (down-left) 0x(768/2) to (1024/2)x768 4. (down-right) (1024/2)x(768/2) to 1024x768 The idea is move the clip (and dock?) to the near edges, holding the distance to them. If the dock is in the up-left, we hold in that area, but if is near to the right down, then move to the new rigth down (holding the space to the finish. For example, if the old screen is 1024x768 and the new is "1920x1024" the final position to the initial position is: 1. Original 10x10, new 10x10 (no change) 2. Original 960x10, new 2048-(1024-960)x10 3. Original 10x700, new 10x(1024-(768-700) 4. Original 960x700, new 2048-(1024-960)x(1024-(768-700) >> IMO should be: >> ---8<-- >>case ConfigureNotify: >> #ifdef HAVE_XRANDR >>if (event->xconfigure.window == DefaultRootWindow(dpy)) >> XRRUpdateConfiguration(event); >> #endif >> break; >> ---8<-- > > Then why not even: > > #ifdef HAVE_XRANDR >case ConfigureNotify: >if (event->xconfigure.window == DefaultRootWindow(dpy)) > XRRUpdateConfiguration(event); > break; > #endif I don't like it, because in "my code" the case option is used (if no xrand, nothing happends), but in "your code" the option is not selected, then the switch will check the next options. And, if this switch-case has default option, in my code is not selected, but in your code the default option is selected. OTOH, this case could be used in the future to other things, not only for xrandr. > >> And finally, someone knows whats happends when >> "XRRUpdateConfiguration" is called? What function/event is called in >> wmaker? > > Don't know anything about this but the man page says it is a callback to > notify the xlib client side about changes in the screen configuration > which is not done automatically to let clients decide when's the best > time to call this. So no event is generated in wmaker but wmaker should > call this if it gets an "RRScreenChangeNotify, or ConfigureNotify (on > the root window)" according to the docs. Ok, I am busy now, but I will check it in the future (after finish with your comments about appicon). > Regards, > BALATON Zoltan Thanks for your comments. kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about dock and clip (xrandr)
On Sun, 6 Jan 2013, "Rodolfo García Peñas (kix)" wrote: Yes, probably the option is check the screen size (p.e. 1024x768), then cut the screen in 4 areas: 1. (up-left)0x0 to (1024/2)x(768/2) 2. (up-right) (1024/2)x0 to 1024x(768/2) 3. (down-left) 0x(768/2) to (1024/2)x768 4. (down-right) (1024/2)x(768/2) to 1024x768 The idea is move the clip (and dock?) to the near edges, holding the distance to them. If the dock is in the up-left, we hold in that area, but if is near to the right down, then move to the new rigth down (holding the space to the finish. For example, if the old screen is 1024x768 and the new is "1920x1024" the final position to the initial position is: 1. Original 10x10, new 10x10 (no change) 2. Original 960x10, new 2048-(1024-960)x10 3. Original 10x700, new 10x(1024-(768-700) 4. Original 960x700, new 2048-(1024-960)x(1024-(768-700) Huh? It's a lot simpler than that (or I'm not really getting your calculations; where does 2048 come from in the 4th line?). I'd put it as the following: if your screen is 1024x768 and put the clip at 10,700 then in Position it is stored as +10-68 (by dividing the screen and checking for which quarter it's in as you described). Then when the resolution changes to 1920x1024 it is placed at 0+10,1024-68 which is at about the same relative position. This is also how the normal X geometry option works. Try these (although it also takes the window size in account to avoid putting the window off-screen): $ xclock -geometry "+100+100" $ xclock -geometry "+100-100" $ xclock -geometry "-100-100" Then why not even: #ifdef HAVE_XRANDR case ConfigureNotify: if (event->xconfigure.window == DefaultRootWindow(dpy)) XRRUpdateConfiguration(event); break; #endif I don't like it, because in "my code" the case option is used (if no xrand, nothing happends), but in "your code" the option is not selected, then the switch will check the next options. And, if this switch-case has default option, in my code is not selected, but in your code the default option is selected. OTOH, this case could be used in the future to other things, not only for xrandr. You're right. But the next case is the default: case which calls handleExtensions() that is a function well equipped with #ifdefs and already has a case for XRANDR too so probably the above should be moved there and then the whole ConfigureNotify case could be removed. (There's not much point in keeping empty cases as you can always add them when you actually need them.) I'm also not sure if we need both the ConfigureNotify on the root window and the RRScreenChangeNotify considering the wording with "or" in the man page. Ok, I am busy now, but I will check it in the future (after finish with your comments about appicon). OK, thanks. :-) Regards, BALATON Zoltan
