On Tue, Mar 24, 2009 at 8:07 PM, Aaron J. Seigo <ase...@kde.org> wrote:
>
>> About NearestScreen(), it could just actually be the next configured
>> screen, like (s+1)%N, or something like that, if we do not have
>> information about where the removed screen was.
>
> we probably have geometry information kicking around somewhere at that point,
> but the other screen's geometry may now have changed as well.
>
> figuring out "next" is not so trivial. which one is "next" if it's the middle
> of three screens? if they are stacked vertically? etc.. again, doable, but
> would take a bit of work.

Yes, that's why I think that, at least in a first approximation, we
could just do (s+1)%n, as anyways cases with more than 2 screens are
probably not that common. Then, if needed, we could refine that
behavior later.
I'll have a quick look at the code today or tomorrow to see if I can
implement that myself.
Cheers,
g

>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to