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 [email protected].

Reply via email to