I guess we should land this patch, given it fixes a compile break and has been successfully tested by two people.

Thanks for testing it out!

This solves the problem with sweetness! :) Thank you a lot! I am not experienced at all with objective C or macos, i just have a maschine to test, but this seems to be working nice and correctly!

Marcel, I've no longer access to a macOS machine. If someone would send me one I'd gladly look into any of these issues. I'm reassigning to @bu5hm4n as he is the last person I know who did any macOS-specific work...

Here's my patch. I tested compiles on the last three macOS SDK versions (10.15, 10.14 & 10.13).

@seeker could you write us a patch? Either upload it here or create a diff here. Any other textform (email, paste) would probably also helpful, but less desirable.

• Can confirm that [[self mainMenu] update] fixes [_mainMenu update]
• _running = 1 can be replaced with [self setValue:[NSNumber numberWithShort:1] forKey:@"_running"]
  • Although _running is no longer declared in NSApplication.h it still exists in the implementation
  • See AppKit.tbd (Ctrl + F, NSApplication._running)

• I think [_mainMenu update] should be [[NSApp mainMenu] update].
• _running = 1 is more problematic, since running is a read-only NSApplication property.

@jayji could you have a look? It's from your commit c03876d611fca41d02513fb07d3d275f64bcf0cd and also has a FIXME there:

For now fixed in the meson ( devs/bu5hm4n/meson) fixed with D6865. works.

@jayji that is very good news. :)

I don't know if this will help, but ecore_cocoa_clipboard_set() (that calls evas_textblock_text_markup_to_utf8) is beta API (the whole cocoa clipboard API is). It was (badly) designed to be used by Elementary only. Maybe the caller of this function can run the evas_textblock_text_markup_to_utf8() first, and pass its output as the data parameter?

Then feel free to refactor the textblock apis into a static lib,

No, that's definitely not a viable solution for us.

Or just quick and dirty dlsym'ing evas_textblock_text_markup_to_utf8 ?

I agree that it probably should not, but this is how the code is written.

This is probably a symptom of T6940.

Ah I misunderstood sorry.
I had thought it was something else from the description.
If it's not visible then I agree it's not a 1.21 problem.

It's a race condition based on a timing issue. It's entirely possible that there is no visible sign of this, which is why I removed it from the 1.21 milestone.

I actually can't replicate this here - is there a small code snippet that I can use?

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

I don't see a crash?

Hey @ajwillia.ms that sounds good :)

Hi @netstar if you're not succeeding I will look - this should really get fixed for 1.21

It seems like this was resolved.

I think probably there are more important issues for the 1.21 release, let's table it for now.

I'll take a look at it. No promises! I've some free time though.

Here you go mike: https://phab.enlightenment.org/D6366

Is this still an issue?

If someone in this ticket isn't interested in resolving this soon then the 1.21 milestone tag should be dropped...

Yes, but what about when it is just setting ->key to the event member? Is this memory guaranteed to persist too?

Should be okay and point to valid address in data segment I reckon?

@netstar and what about the key string allocation?

This was causing issue in Fyne.io using EFL.

I can have a little look.

I'm not an expert on mac system programming or whatever language the .m files are written in.

Reopen if this recurs.