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