🚀 go-pugleaf

> If we implemented this feature, and you clicked on a stack which contained 
> unselected objects intermingled with selected ones (e.g., objects under 
> the cursor are A B c D e f where upper-case letters are selected and
> A is in front), would you expect it to select the frontmost unselected 
> object (c), or the object immediately behind the backmost selected object 
> (e)?

If that stack was already the selection before starting the
cycle-through, I think I would expect it to pick the first unselected
under what is already selected, which would be e.

But in practice that is going to be a relatively rare situation. They
cycle thru thing is crucially important for efficiency, based mainly on
its simplicity. I use it constantly, but almost always for contiguous
(contiguous, that is, among what is UNDER THE CURSOR) selections. When
non-contiguous selections are involved, the tedium of using the Layers
palette is not unreasonable. So for those kinds of details, I could go
either way. It doesn't need to be a complicated thing; that's the point.

For example, simply cycling through the objects under the cursor in a
"next object below" fashion is fine. I don't really care for it to be
complicated by another modifier to make it cycle in the other direction.
When it reaches the bottom of the stack (under the cursor), it should
simply cycle through to the top object again.

JET