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 Mac OS X (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-05 10:00 UTC by Julien Nabet
Modified: 2020-02-13 15:50 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


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.