Bug 130453 - [macOS] Convert from Carbon to Cocoa framework
Summary: [macOS] Convert from Carbon to Cocoa framework
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All macOS (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: macOS-UI-polish
  Show dependency treegraph
 
Reported: 2020-02-05 10:00 UTC by Julien Nabet
Modified: 2023-01-18 23:23 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2020-02-05 10:00:48 UTC
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:
Comment 1 Alex Thurgood 2020-02-06 07:00:16 UTC
Shouldn't we be looking at Swift instead of Objective-C ?
Comment 2 Julien Nabet 2020-02-06 08:59:55 UTC
(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.
Comment 3 Roman Kuznetsov 2020-02-07 06:06:06 UTC
Tor, possibly you have some opinion about this enh?
Comment 4 Tor Lillqvist 2020-02-07 07:12:10 UTC
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.
Comment 5 Julien Nabet 2020-02-07 07:55:04 UTC
Thorsten: considering the patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=9d31d8f1d8d3a73f8c07ca39f5ed45e2bb7b088c, thought you might have some opinion here.
Comment 6 Thorsten Wagner 2020-02-07 10:24:51 UTC
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.
Comment 7 Julien Nabet 2020-02-07 10:50:15 UTC
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?
Comment 8 Michael Meeks 2020-02-07 15:48:39 UTC
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.
Comment 9 Miklos Vajna 2020-02-10 08:22:43 UTC
Sure, we can discuss this in 3 days.
Comment 10 Tor Lillqvist 2020-02-10 08:27:54 UTC
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
Comment 11 Miklos Vajna 2020-02-13 15:50:48 UTC
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.
Comment 12 Patrick Luby 2023-01-18 22:48:05 UTC
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.
Comment 13 Caolán McNamara 2023-01-18 23:23:21 UTC
caolanm->ilmari: I think you have ended up as this years coordinator (de facto/jure?) of budget 2023