Description: Carbon was a framework to help migrating MacOs applis from before OSX. Cocoa is the framework to use. It would allow better integration of LO in MacOs. Steps to Reproduce: N/A Actual Results: N/A Expected Results: N/A Reproducible: Always User Profile Reset: No Additional Info:
Shouldn't we be looking at Swift instead of Objective-C ?
(In reply to Alex Thurgood from comment #1) > Shouldn't we be looking at Swift instead of Objective-C ? It seems Cocoa framework is compatible with both. Now, if Swift is the future, I suppose that evolutions on MacOs code part should indeed be in Swift. BW, just to put it clearly, I created this enhancement so there's some trace but I don't know Cocoa, Swift or Objective-C and don't have a Mac anymore since 2017.
Tor, possibly you have some opinion about this enh?
Without any concrete suggestions there is little to say. But in general, yeah, I am sure there is lots that could be done. Using Objective-C++ makes it trivial to interface with cross-platform LibreOffice code. (The same source file can freely use both C++ and Objective-C APIs.) If one started rewriting stuff in Swift just to be more "cool", one would also need to add a bunch of glue.
Thorsten: considering the patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=9d31d8f1d8d3a73f8c07ca39f5ed45e2bb7b088c, thought you might have some opinion here.
APIs of SWIFT and Objective+C++ are very similar/exchangable. I don't know if SWIFT is really the future. I fact both can be used. To integrate with LO code Objective-C++ should be the way to go from my point of view. Cocoa adoption have to be done absolutely since Carbon APIs do not seem to be maintained by Apple straightforward (see tdf#122218 for example), but Cocoa adoption is a larger issue: (1) VCL is a framework for complete layout and management of graphical interfaces. Native widgets are called for displaying themtelves, text is displayed separately by VCL using another native call, event loop is done by VCL and so on. This is possible using Carbon calls, GTK and QT are implemented similar as far as I understood. (2) Cocoa is an object-oriented framework. To adopt Cocoa, classes have to be defined to superimpose VCL and to replace VCL functionality by Cocoa, not to call Cocoa functionality from VCL. Probably a redesign of VCL will be required to offer both ways in the future.
Thorsten: very interesting! I didn't think about such a refactor of VCL part. Caolán: since it concerns VCL (so not Mac specific part), thought you might be interested in this one. Michael: I think it could be interesting to put this in next ESC, would it be ok?
For the ESC agenda - best to poke Miklos (CC'd) I think. I would love us to move to a modern rendering API here, we have a Skia backend that can provide that nicely which is coming along very nicely I think. Lubos might have some thoughts here. Probably there is more than just rendering API we would need to upgrade (I guess), if someone wants to do the porting, that's great, and totally agreed with Tor & Thorsten that continuing to use our mix of objective-C and C++ is the right approach for now =) HTH.
Sure, we can discuss this in 3 days.
I don't think this issue is about low-level rendering as such, but about fitting the whole application plumbing into the Cocoa document architecture, NSDocument etc. See https://developer.apple.com/documentation/appkit/documents_files_and_icloud/developing_a_document-based_app?language=objc
https://lists.freedesktop.org/archives/libreoffice/2020-February/084440.html discussed today in the ESC call. If there is more input needed, probably best to discuss it async on the dev list.
I saw this bug in a budgeting e-mail on the developer's mailing. This bug has been open for almost 3 years. Maybe we can narrow the scope of this bug to some concrete tasks. Here is some of the tasks that can think of: 1. Replace any remaining Carbon functions with non-Carbon functions. There aren't a lot of Carbon functions that I can see, but the following shared libraries are still linked to the Carbon framework: libAppleRemotelo.dylib libmacabdrv1.dylib libuno_sal.dylib.3 libvclplug_osxlo.dylib 2. Replace any deprecated macOS functions with supported functions. Apple routinely changes function names every few years, even in Cocoa and other frameworks. LibreOffice is still using some deprecated macOS functions and since Apple may remove deprecated functions from a future version of macOS, a second task for this bug could be replacing deprecated code within SAL_WNODEPRECATED_DECLARATIONS_PUSH/SAL_WNODEPRECATED_DECLARATIONS_POP #pragma blocks. I am planning on working on the second task for the native accessibility code in vcl/osx later this year. I am planning on replace the deprecated, heavyweight NSAccessibility informal protocol with the new, lightweight formal protocol.
caolanm->ilmari: I think you have ended up as this years coordinator (de facto/jure?) of budget 2023