If I implemented a macOS-specific bug fix, where some macOS-specific Objective-C file(s) were replaced with Swift language file(s), is there a process whereby such a submission would be accepted? As a specific example, what if I replaced "core/vcl/osx/printaccessoryview.mm" with "core/vcl/osx/printaccessoryview.swift" during the process of fixing the bugs listed below? * 2014-05-19 "Bug 78916 - Custom page size missing from print dialog" * 2021-12-13 "Bug 146212 - Print Preview Dialog: Page Orientation not shown on macOS" * 2022-02-23 "Bug 147615 - PRINTING: macOS Impress print dialog does not provide access to select printer's Paper Size"
IMHO, it's more a question you should ask on dev mailing list (see https://wiki.documentfoundation.org/Development/Mailing_List).
(In reply to zbugs from comment #0) > If I implemented a macOS-specific bug fix, where some macOS-specific > Objective-C file(s) were replaced with Swift language file(s), is there a > process whereby such a submission would be accepted? > The basic question I guess, aside from any other UI considerations, would be whether stuff written in Swift, which is released under the Apache 2.0 licence, is compatible with the dual licence conditions of the LibreOffice project?
(In reply to Alex Thurgood from comment #2) > (In reply to zbugs from comment #0) > > If I implemented a macOS-specific bug fix, where some macOS-specific > > Objective-C file(s) were replaced with Swift language file(s), is there a > > process whereby such a submission would be accepted? > > > > The basic question I guess, aside from any other UI considerations, would be > whether stuff written in Swift, which is released under the Apache 2.0 > licence, is compatible with the dual licence conditions of the LibreOffice > project? Indeed! I hadn't thought about license issue! Michael: any thoughts here?
Of course, this is not my decision to make - you'd need to ask the ESC - let me include Miklos to put this on the agenda (and would be great to see you attend a call quickly). The license for the implementation of Swift itself is permissive, and would (I imagine) not cover the source files themselves anyway; so unless I'm missing something I don't see a problem with using Swift. The question of whether it's a good idea to re-write existing working Objective-C code into Swift is another one; and - since I do almost no work on that code itself - I've no view =) people who step up and maintain that piece of code would normally make that sort of decision. Patrick would prolly have some useful and better informed thoughts here though. Thanks for the CC Julien ! =)
> let me include Miklos to put this on the agenda Will do.
(In reply to Julien Nabet from comment #1) > … ask on dev mailing list Regarding communication, I did review of the developer documentation, mailing list archives, bugzilla issues (open & closed), and IRQ channels regarding the considerations for using Swift. My thinking to create an issue tracker ended up being to… 1. have a clear standalone thread on this particular topic 2. specifically create a single URL endpoint for this topic 3. avoid mailing list clutter and the transcient-ish nature of IRQ channels 4. provide a placeholder for any actions/tasks which may need to be done if proceeding forward (In reply to Michael Meeks from comment #4) > The question of whether it's a good idea to re-write existing working > Objective-C code into Swift is another one; Good question. In general, the leading champion of Objective-C (Apple) has been visibly moving away from Obj-C and decisively going with Swift since June 2014 (public release date)… nearly 9 years ago. In this specific case, I am looking to fix 3 bugs (not yet assigned) related to macOS specific printing NSPrintOperation/NSPrintPanel. This code has been broken as far back as 2014-05-19 (Bug# 78916). Long time broken and missing some fix'n. > and … people who step up and maintain that > piece of code would normally make that sort of decision. Yes. A code review is key. The expectation is that the Swift code will agreeably be, among other things, more readable and easier to maintain than the replaced Obj-C. Thanks for all your time and attention to this issue. --Marc
(In reply to Alex Thurgood from comment #2) > …, aside from any other UI considerations, … Note: The scope here is for some specific limited use of the Swift Language and *not* any use of SwiftUI interface elements. So, any fixes would use the same UI/AppKit/Cocoa approach as currently used. --- A detail on "Bug# 78916 - Custom page size missing from print dialog" is that the original report was for Linux. However, I have known, from personal experience, that the same issue has been on Mac OS X/macOS LibreOffice for a long, long time. And, on 2018-04-09, Bryce also added in the comments: > This bug is also a problem on MacOS version of LibreOffice. > Not being able to choose a paper size or orientation is a real problem.
(In reply to zbugs from comment #7) > (In reply to Alex Thurgood from comment #2) > > …, aside from any other UI considerations, … > > Note: The scope here is for some specific limited use of the Swift Language > and *not* any use of SwiftUI interface elements. So, any fixes would use the > same UI/AppKit/Cocoa approach as currently used. > ... Just for the record, there's an enhancement bugtracker concerning migration about Carbon parts into Cocoa. (see tdf#130453)
Some feedback from ESC " * Swift for macOS-specific code? (Julien) + see https://bugs.documentfoundation.org/show_bug.cgi?id=154849 for context + it doesn't make much difference either way (Cloph) + also think: if there is no technical reason to switch, then why switch from Objective-C (Stephan) + not looking forward to invest the necessary configure / gbuild work + unless there is a compelling technical reason + Apple deprecates technology fast (Michael M) + if the person wants to also do the gbuild work, why not? + idea was: convert, then fix things (Caolan) + so these are separated cleanly. => first do the fixing, then the conversion ideally (Miklos) " (see https://lists.freedesktop.org/archives/libreoffice/2023-April/090286.html) zbugs: I hadn't asked but do your patches in Swift build? Indeed, some people talk about gbuild (the LO specific tool to build) potential work required if Swift should be dealt with.
(In reply to Julien Nabet from comment #9) > ... > zbugs: I hadn't asked but do your patches in Swift build? Indeed, some > people talk about gbuild (the LO specific tool to build) potential work > required if Swift should be dealt with. Argh, I should have re-read, you indicated "if I implemented", I thought you had already some ready patches but I had just missed the "IF", so it was hypothetical. It's when I read Tor's message (https://lists.freedesktop.org/archives/libreoffice/2023-April/090289.html) I realized this. Searching about Swift and C++, I found https://www.swift.org/cxx-interop-workgroup/ so it seems indeed Swift not ready for interop with C++ since they're working on it. So if you consider that C++ is the main language of LO + LO uses a specific building tool (gbuild), I'm not sure proposing patches in Swift is a good idea (at least for the moment).
(In reply to Julien Nabet from comment #9) > Some feedback from ESC … (In reply to Julien Nabet from comment #10) > Argh, I should have re-read, you indicated … Julien, Thank you for facilitating the communications. Great comments from everyone! I will circle back with additional details on what I'm proposing to contribute… after I'm past a 48 hours deadline time crunch. --Marc (bugz)
Swift and C++ seems to be work in progress as per https://www.swift.org/cxx-interop-workgroup/ Since the question posed in this bug is valid, setting to NEW. Not sure how actionable this is and if it should be closed, but certainly not unconfirmed.
Direct C++ interoperability is a new feature in the Swift 5.9 release. Swift 5.9 was released on September 18, 2023 for linux, macOS and windows. Official C++ interoperability documentation is now live at Swift.org and provides an up-to-date guide for mixing Swift and C++: "Mixing Swift and C++" https://www.swift.org/documentation/cxx-interop "Setting Up Mixed-Language Swift and C++ Projects" https://www.swift.org/documentation/cxx-interop/project-build-setup GitHub: apple/swift/…/docs/CppInteroperability https://github.com/apple/swift/tree/main/docs/CppInteroperability