Re: NSCollectionView selection behavior is insanely bad

[Steve Mills]

On Apr 26, 2017, at 18:13, Greg Weston  wrote:

>> Instead of doing the right thing when shift-clicking (selecting a range from 
>> the anchor), it simply adds/removes the clicked item to/from the selection. 
>> That's unlike pretty much any Apple matrix-of-items selection behavior ever.
> 
> You mean it selects like Finder icon views have since 1984? Like a collection 
> of discrete items instead of a continuum?

Yes, and since it's a replacement for other non-Finder-icon-view type things 
(e.g. IKImageBrowserView), its the wrong behavior. That's why I said "matrix of 
items". Finder icon view is not that—they can be arranged with complete 
disregard to columns and rows.

Steve via iPad

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSCollectionView selection behavior is insanely bad

[Greg Weston]

> Instead of doing the right thing when shift-clicking (selecting a range from 
> the anchor), it simply adds/removes the clicked item to/from the selection. 
> That's unlike pretty much any Apple matrix-of-items selection behavior ever.

You mean it selects like Finder icon views have since 1984? Like a collection 
of discrete items instead of a continuum?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSCollectionView selection behavior is insanely bad

[Steve Mills]

Since IKImageBrowserView is deprecated and buggy in recent versions of macOS, 
I've been switching to NSCollectionView. Holy crap, does its selection behavior 
suck. Instead of doing the right thing when shift-clicking (selecting a range 
from the anchor), it simply adds/removes the clicked item to/from the 
selection. That's unlike pretty much any Apple matrix-of-items selection 
behavior ever. I've been trying to make it right by subclassing 
NSCollectionView to override mouseDown:, mouseDragged:, mouseUp:, 
setSelectionIndexPaths:, selectItemsAtIndexPaths:scrollPosition:, 
deselectItemsAtIndexPaths:, selectAll:, and deselectAll:, as well as keyDown:, 
keyUp:, and tons of the moveUp/Down/Backward/Forward*: methods.

Has anybody done this, or just lived with the half-assed default 
implementation? Anybody know of a free public implementation or even a complete 
replacement for NSCollectionView that handles shift-key selection the right 
way? Coupled with the other bugs/problems I've asked about and not gotten any 
answers to, there's got to be something better out there than NSCollectionView.

--
Steve Mills
Drummer, Mac geek

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Determining if an X,Y position will cause a Move or Resize?

[Dave]

Hi All,

I have an X,Y that is in another Application’s Window, is there a way of 
determining if that the Mouse is Dragged at that position whether the Drag will 
be a Window Move or a Window Resize operation. 

Basically I just want to tell if the Mouse is in the Window Title Bar (move) or 
in the Window Frame (resize).

Thanks a lot
All the Best
Dave

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Detecting if current user owns the screen (screen lock/FUS)

[Uli Kusterer]

Lock screen still gives the name of the user behind the screen lock.

Mühevoll auf meinem Telefon getippt.

> On 21. Apr 2017, at 11:43, Stephane Sudre  wrote:
> 
> SystemConfiguration.framework?
> 
> You can:
> 
> - retrieve the current uid,gid, user name with SCDynamicStoreCopyConsoleUser
> - be notified via a C callback when the console user changes
> (SCDynamicStoreCreate, SCDynamicStoreKeyCreateConsoleUser(),
> SCDynamicStoreSetNotificationKeys, SCDynamicStoreSetDispatchQueue or a
> more classic runloop source) and then then call
> SCDynamicStoreCopyConsoleUser.
> 
> Note that when the login window is displayed, the current user name is
> "loginwindow".
> 
> I've never checked which uid or user name was returned when the screen
> is locked.
> 
> 
> On Fri, Apr 21, 2017 at 9:57 AM, Uli Kusterer
>  wrote:
>> Hi,
>> 
>> I have an application (think hardware driver) that runs as a particular 
>> (GUI) user. Now, if that user is switched out using Fast User Switching or 
>> the screen lock has engaged, I want to prevent the driver from working (as 
>> the user sitting in front of the computer with access to the hardware is 
>> obviously not them).
>> 
>> The only documented API I've found is 
>> NSWorkspaceSessionDidResignActiveNotification etc., but this doesn't help me 
>> because it only notifies me when the state changes, it doesn't let me obtain 
>> an initial state (I suppose I could assume if I'm running as a user, my 
>> session is active, but would prefer actually knowing).
>> 
>> I've also found that CGSessionCopyCurrentDictionary() contains an 
>> undocumented key that lets me know whether the screen lock is engaged, but 
>> that reports the screen as not locked when the user is still logged on, but 
>> switched out using fast user switching.
>> 
>> Is there any official, supported way to determine whether the user my app is 
>> running as actually owns the screen and screen lock is not engaged that I 
>> could use for this purpose? Since I only need to know the current state when 
>> the user actually triggers my device, a polling API would be fine.
>> 
>> Cheers,
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/dev.iceberg%40gmail.com
>> 
>> This email sent to dev.iceb...@gmail.com
> 
> 
> 
> -- 
> Packaging Resources - http://s.sudre.free.fr/Packaging.html
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com