Sat, Mar 21
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...
Tue, Mar 10
Here's my patch. I tested compiles on the last three macOS SDK versions (10.15, 10.14 & 10.13).
Mon, Mar 9
@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)
Jan 13 2020
- I think [_mainMenu update] should be [[NSApp mainMenu] update].
- _running = 1 is more problematic, since running is a read-only NSApplication property.
Jan 12 2020
Jan 22 2019
Jan 14 2019
Aug 25 2018
Aug 18 2018
For now fixed in the meson ( devs/bu5hm4n/meson) fixed with D6865. works.
@jayji that is very good news. :)
Aug 17 2018
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?
Aug 16 2018
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.
Jul 25 2018
This is probably a symptom of T6940.
Jul 4 2018
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.
Jul 3 2018
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?
Jun 29 2018
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 :)
Jun 28 2018
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.
Jun 22 2018
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?
Jun 21 2018
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.
Jun 20 2018
I'm not an expert on mac system programming or whatever language the .m files are written in.
Jun 14 2018
Reopen if this recurs.