On 11/24/19 1:37:17 PM, Allan Odgaard via Cocoa-dev wrote:
On 24 Nov 2019, at 22:28, Kurt Bigler via Cocoa-dev wrote:
[…] The idea for least inefficiency given the global updating pass is to defer
(akin to lazy evaluation) the actual menu item updating until the last
possible moment. The
g would be so obscure as to be unsupportable in Cocoa.
Thanks in advance.
-Kurt Bigler
___
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)lis
On 8/11/19 8:26:38 PM, Kurt Bigler via Cocoa-dev wrote:
So now I'm getting osEvt, mouseDown, and updateEvt, but no activateEvt, and so
the mouseDown only tries to activate each time. I can probably workaround that
by accepting the first click.
Adding a Carbon window event handler seems
On 8/11/19 8:26:38 PM, Kurt Bigler via Cocoa-dev wrote:
...Yes, doing that yields an app that is closer to working than what I've seen
yet. Mouse ups are sometimes being dropped though. And while Carbon portions
are working much better, Cocoa windows are now non-interactive, no l
On 8/10/19 2:38:00 PM, Uli Kusterer wrote:
On 10. Aug 2019, at 23:02, Kurt Bigler wrote:
Currently if I call NSApplicationMain instead of my regular Carbon event loop
(which is based on ReceiveNextEvent), NSApplicationMain returns immediately. I
don't call NSApplicationMain immed
On 8/10/19 10:30:45 PM, Glenn L. Austin wrote:
On Aug 10, 2019, at 10:20 PM, Kurt Bigler via Cocoa-dev
wrote:
I implemented hitTest to return self in my NSView subclass. It made no
difference.
After that, I tried having hitTest call the super method to see what it
returned. For the
On 8/10/19 10:20:34 PM, Kurt Bigler via Cocoa-dev wrote:
On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
Either way, instead of going back & forth on this, why don’t you try
implementing an NSView subclass without hitTest returning self and see if that
view gets -mouseDown:. Then over
On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
On Aug 10, 2019, at 3:38 PM, Uli Kusterer wrote:
On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote:
On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev mailto:cocoa-dev@lists.apple.com&g
On 8/10/19 2:21:05 PM, Rob Petrovec wrote:
On Aug 10, 2019, at 3:12 PM, Kurt Bigler wrote:
On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
wrote:
The NSView subclasses involved are receiving drawRect: messages but are not
receiving
On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
wrote:
The NSView subclasses involved are receiving drawRect: messages but are not
receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.
I have 5
On 8/10/19 2:16:41 AM, Uli Kusterer wrote:
The Cocoa event handling code uses CarbonEvents under the hood. AFAIR, you can
switch to the Cocoa event loop right away, and Carbon windows will just keep
working.
You're saying some interesting things. Given the demise of 32-bit, if this is
still
rbon event stuff and just rebuild from
the ground up, but I'm hoping I can solve these issues since I foresee a more
gracious process this way.
Thanks in advance for any help.
-Kurt Bigler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
I would like to be able to traverse the top-level object list in a macOS nib
without instantiating the objects. But I'd like to be able to get at the
attributes of each top-level item to decide whether to instantiate it, and then
of course to control instantiation on an object-by-object basis b
On 12/18/16 12:33:53 PM, Ken Thomases wrote:
On Dec 18, 2016, at 2:15 AM, Kurt Bigler wrote:
But if in Displays I set the resolution to 1920x1200 "More Space", then I can't
get the backing store to match the 2880x1800 physical display resolution. I need my
NSView's
erpolationNone as would be required for pixel-exact
bitmaps. If I use anti-aliasing the problem of course gets less obviously
objectionable, but lacks the crispness which is required for this content.
Thanks for any help.
-Kurt Bigler
___
Coc
On 11/21/12 7:56 AM, Kyle Sluder wrote:
On Wed, Nov 21, 2012, at 07:25 AM, Ross Carter wrote:
The way to do this is by subclassing NSGlyphGenerator to return null
glyphs for text that has your custom Hidden attribute. A WWDC video from
a few years back shows how.
Specifically, start watching f
xt views, one with hidden text included, and
one without, and simply swap the two views to implement show/hide of hidden text.
Is there a better way? I would rather not get deep into a highly-structured
text document kind of model in order to achieve something like this (assuming
th
On 8/2/12 12:29 PM, Charles Srstka wrote:
On Aug 2, 2012, at 1:57 PM, koko wrote:
Thanks.
I asked the question because I saw here one time that "you don't want to be the app
causing 32-bit versions" to load.
As long as it is not a system resource problem, then all is well as far as I am
co
th and I have crafted a lot by trial and error.
Mostly I'd like to avoid creating unnecessary performance hits, since this
outline view gets updated at a high rate by incoming realtime data.
All thoughts are welcome. Thanks in advance.
-Kurt Bigler
_
st that is what I've been able to figure out
so far, but my cocoa experience is limited.
I'd appreciate any comments on the issue of detecting clicks in outline view
cells as well as the possible reason for the unexpected setObjectValue
messages.
Thanks in ad
20 matches
Mail list logo
