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
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
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
> 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
> 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
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
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
>> >> 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
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
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
> 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
>>
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
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
13 matches
Mail list logo
