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
