Re: is there a way to determine if an NSButton is toggleable ?
NSButton is interesting in that it separates out the state (e.g. `isHighlighted` and `state`) from the presentation of that state. The state manipulation behavior is totally uniform, i.e. the `state` property always toggles between Off and On when any button is clicked. Most buttons aren't configured to draw differently when On, so you don’t notice it. Subclassers often just ignore this and implement whatever drawing behavior they want, but if you want to be sensitive to the configuration, you’ll want to check the showsStateBy mask on the cell. • For a Toggle button, which exchanges contents based on state, the NSContentsCellMask bit will be set. • For a On/Off button, which reflects the state in the button artwork, the NSChangeBackgroundCellMask bit will be set. It’s legal for a button cell to have any combination of bits configured, but none of the built-in NSButtonTypes set both at once. - Jeff > On Aug 20, 2018, at 3:04 AM, Guillaume Laurent > wrote: > > Hi all, > > > For a custom UI I’ve had to write a custom control deriving from NSButton, > which highlights itself in a special way on mouse-over. In the method which > does the highlighting, I check if the button’s state is either .on or .off, > so I know which title or alternateTitle to display. But I realized that, no > matter the button's type, the state is always toggled on click. That is, even > if the button’s type is set to MomentaryPushIn, the button’s state is toggled > after a click. I’d have thought that this was the case only for > OnOff/Toggle/Switch… types. > > Since there is no NSButton.type getter, is there a way to determine if the > button’s type is toggleable or not ? And what is the reason for switching > state for types like MomentaryPushIn ? > > > Thanks, > > Guillaume. > ___ > > 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/jnadeau%40apple.com > > This email sent to jnad...@apple.com ___ 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: Custom keyboard with search bar not behaving
On Aug 20, 2018, at 13:35, Saagar Jha wrote: > > What does [UIApplication.sharedApplication.keyWindow > performSelector:@selector(firstResponder)] give you? It correctly shows it to be the UITextView I currently have in the wrapper app, both before and after I activate and cancel the search bar. It seems like the UIInputViewController's textDocumentProxy isn't handling the change in input views properly. Steve via iPhone ___ 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: Custom keyboard with search bar not behaving
What does [UIApplication.sharedApplication.keyWindow performSelector:@selector(firstResponder)] give you? Saagar Jha > On Aug 20, 2018, at 06:16, Steve Mills wrote: > > I guess I'll try this list as well. > > I’m implementing a custom keyboard for iOS. It contains a UISearchBar the > user can use to filter the “keys” they can use to type. When the search > button is used, I call [searchBar resignFirstResponder] to have the search > bar give up its capture of input. The insertion point has been and still will > be blinking in the document view, yet calling [self.textDocumentProxy > insertText:s] no longer inserts text into the document. > > I thought this was working earlier in the project development. Any ideas? I > see a similar feature working in Google's Gboard. Maybe I need to use a fake > search bar so the text input chain never gets disturbed? > > BTW, I've only tested from the Simulator available on my work Mac, which is > still maddeningly stuck on macOS 10.10. > > -- > 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/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.com ___ 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: Carbon -> Cocoa
> On Aug 18, 2018, at 11:19 AM, Stephane Sudre wrote: > > It might be the new Carbon once: > > - there is ABI stability in Swift. This could be not before late 2019. > > - the new APIs are only available in Swift. Is Swift NIO a hint this > is coming sooner than expected? By “NIO” do you mean the new Network.framework? They did only demo the Swift API at WWDC, but it has a full C API too. (Which makes sense, since part of its goal is to drag C developers away from the POSIX sockets API.) > I don't know. I don't use networking frameworks. You should consider adopting one at some point. There are several benefits they provide that aren’t available with POSIX APIs, like faster connection startup, and transparently switching between WiFi and cellular. (Stuart Cheshire’s various WWDC talks go into detail.) —Jens ___ 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: Carbon -> Cocoa
> On Aug 20, 2018, at 12:43 AM, Alastair Houghton > wrote: > > I’d tentatively suggest that it’s likely that Swift will develop some means > of interfacing more directly with C++ code in the future, which should make > this easier rather than harder. There are tools like SWIG for generating inter-language glue code; I don’t know if it supports C++ and Swift, though… —Jens ___ 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: is there a way to determine if an NSButton is toggleable ?
The docs indicate that the button “type” is not actually a property itself. The setter simply sets some group of properties to reflect the behavior represented by the button type constant. NSButtonCell showsStateBy property value might be the closest thing. You might also put a breakpoint on setState: to see if it is being set when it shouldn’t, and maybe by whom. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" > On Aug 20, 2018, at 4:04 AM, Guillaume Laurent > wrote: > > Hi all, > > > For a custom UI I’ve had to write a custom control deriving from NSButton, > which highlights itself in a special way on mouse-over. In the method which > does the highlighting, I check if the button’s state is either .on or .off, > so I know which title or alternateTitle to display. But I realized that, no > matter the button's type, the state is always toggled on click. That is, even > if the button’s type is set to MomentaryPushIn, the button’s state is toggled > after a click. I’d have thought that this was the case only for > OnOff/Toggle/Switch… types. > > Since there is no NSButton.type getter, is there a way to determine if the > button’s type is toggleable or not ? And what is the reason for switching > state for types like MomentaryPushIn ? > > > Thanks, > > Guillaume. > ___ > > 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/cocoa-dev%40esoteritech.com > > This email sent to cocoa-...@esoteritech.com ___ 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: Carbon -> Cocoa
On 20 Aug 2018, at 14:27, Casey McDermott wrote: > > Moving anything from Obj-C to C++ objects is easy, because the .mm file can > contain both. > > Moving back is hard, because C++ can't reference Obj-C classes. It can, but only if it’s either (a) in a .mm file, or (b) prepared to call the Objective-C runtime functions. You can include the Objective-C runtime from a C++ file, and you’ll get all the base types (so, not the Foundation or AppKit types, or any of your own, but you will get “id”, “Protocol”, “Class” and so on), and can make method calls using appropriate Objective-C runtime APIs. I’m not saying either of those would be better than what you’ve done, mind. >>> I’d tentatively suggest that it’s likely that Swift will develop some means >>> of > interfacing more directly with C++ code in the future, which should make this > easier rather than harder. > > This link says that C++ support is now marked "out of scope" in Swift 3.0: > https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift > I didn't find any mention of future support being planned. Sure, that may well be the case. I can’t imagine anyone thinking it isn’t a desirable feature for Swift to have at some point, though, and Swift being Open Source, any of a very large pool of people and companies could work on this if they wanted. I think it’s inevitable that Swift will at some point develop better support for C++ objects. Kind regards, Alastair. -- http://alastairs-place.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
Re: Carbon -> Cocoa
>> >> It's annoying but not dreadful to link C++ code into Cocoa via >> >> Objective-C. >> Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” >> and then use C++ wherever you wish. That part is easy, and at the beginning we were very optimistic. The problem is, we already have an MVC architecture written in C++ / PowerPlant. It has many business logic quirks. We have to link the C++ controllers to Cocoa controllers, and each C++ view field to a Cocoa control (usually with subtly different behaviors). Moving anything from Obj-C to C++ objects is easy, because the .mm file can contain both. Moving back is hard, because C++ can't reference Obj-C classes. We use an intermediate C++ linker class with void pointers to Obj-C objects in the header. Then a .mm source file that talks with both. What used to be controller -> field becomes Cocoa controller -> C++ controller -> C++ field -> linker -> Cocoa control. The alternative is to rewrite all the business logic in Cocoa, but that would require a year of testing to get it all right again. Then maintaining two code bases from here on out. >> I’d tentatively suggest that it’s likely that Swift will develop some means >> of interfacing more directly with C++ code in the future, which should make this easier rather than harder. This link says that C++ support is now marked "out of scope" in Swift 3.0: https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift I didn't find any mention of future support being planned. Casey McDermott Turtle Creek Software ___ 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
Custom keyboard with search bar not behaving
I guess I'll try this list as well. I’m implementing a custom keyboard for iOS. It contains a UISearchBar the user can use to filter the “keys” they can use to type. When the search button is used, I call [searchBar resignFirstResponder] to have the search bar give up its capture of input. The insertion point has been and still will be blinking in the document view, yet calling [self.textDocumentProxy insertText:s] no longer inserts text into the document. I thought this was working earlier in the project development. Any ideas? I see a similar feature working in Google's Gboard. Maybe I need to use a fake search bar so the text input chain never gets disturbed? BTW, I've only tested from the Simulator available on my work Mac, which is still maddeningly stuck on macOS 10.10. -- 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
is there a way to determine if an NSButton is toggleable ?
Hi all, For a custom UI I’ve had to write a custom control deriving from NSButton, which highlights itself in a special way on mouse-over. In the method which does the highlighting, I check if the button’s state is either .on or .off, so I know which title or alternateTitle to display. But I realized that, no matter the button's type, the state is always toggled on click. That is, even if the button’s type is set to MomentaryPushIn, the button’s state is toggled after a click. I’d have thought that this was the case only for OnOff/Toggle/Switch… types. Since there is no NSButton.type getter, is there a way to determine if the button’s type is toggleable or not ? And what is the reason for switching state for types like MomentaryPushIn ? Thanks, Guillaume. ___ 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: Carbon -> Cocoa
> On 17 Aug 2018, at 19:51, Jeremy Hughes wrote: > >> Of course, the C++ business logic doesn't need any changes. The concern is, >> how long will it last? Seems like the future is an entirely Swift-based API >> that replaces Objective-C Cocoa in 5 years, with no easy way to link to >> other languages. > > Core parts of Webkit are written in C++, so I think you’re safe with that. > > I haven’t tried to interface between Swift and C++, but I think it’s possible > and will probably get easier. You could ask in the Swift forums. It’s not currently possible, from what I’ve tried, the best way to do this is to wrap a C++ class in an ObjC++ class. ___ 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: Carbon -> Cocoa
On 18 Aug 2018, at 20:45, Mike Crawford wrote: > > "older OS versions", porting to 10.6 or later vs. 10.10 or later: > > I at first intended all the drivers I write for my clients to work on > Snow Leopard 10.6, but after actually attempting to do so I settled > upon supporting El Capitan 10.11, sometimes just Sierra 12.6. Slightly off topic, but drivers are definitely the worst case, as sometimes you need to use the old SDKs to build them, and the Xcode team is, in my view, somewhat overenthusiastic about dropping support for them… the Deployment Target setting isn’t always sufficient. I do wonder, actually, how much thought is given to those of us who have KEXTs to build when pondering whether or not to drop an SDK from Xcode. There have been some other pain points in recent macOS versions relating to KEXTs also (changes to driver signing, the recent blocking of third-party KEXTs until the user visits System Preferences to confirm their installation, etc.). One would almost think Apple didn’t want us writing low-level code… Kind regards, Alastair. -- http://alastairs-place.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
Re: Carbon -> Cocoa
On 17 Aug 2018, at 17:45, Casey McDermott wrote: > >>> By now, Cocoa may be the new Carbon. if your app is large, I'd wait to >>> see what happens with Marzipan. > > This is true, and very scary. Makes us wonder about sunk cost fallacy. I don’t actually think it’s very likely that Marzipan will replace Cocoa (except possibly for things like calculator, to-do list and notes type apps). My impression is that it’s really a way to run iOS apps, which typically have a much simpler UI and far fewer features, on the macOS. That makes sense for some types of software, for sure, but I think larger packages are likely to want to stick with AppKit. > It's annoying but not dreadful to link C++ code into Cocoa via Objective-C. Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” and then use C++ wherever you wish. > Throw in Swift and future APIs that are Swift-dominated, and it becomes > harder. How soon will it be impossible? It’ll never be impossible, but you’re right at the moment you’ll need either an Objective-C or vanilla C API to wrap your C++. I’d tentatively suggest that it’s likely that Swift will develop some means of interfacing more directly with C++ code in the future, which should make this easier rather than harder. Kind regards, Alastair. -- http://alastairs-place.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
