MacOS rewrite

[sciurius]

No description provided.

[Desbeers]

As I wrote to the list, I volunteer to update the current macOS wrapper for ChordPro.

I wrote a proof of concept macOS SwiftUI wrapper:

https://github.com/Desbeers/ChordProMac

For now, it is just calling the official binary to do the hard work:

/Applications/ChordPro.app/Contents/MacOS/chordpro

My main goal for now was to bridge SwiftUI with the core ChordPro binary.

That is working now, so adding more arguments like settings to the core is not that hard to do.

A harder struggle will be to include the core into the macOS package itself but I’m sure that will be doable. Something new for me, but I’m sure we find out how to do!

Eventually, I would love to have this wrapper in the official ChordPro source! This is not meant to be an alternative implementation :-)

I try to keep is a simple as possible. No external dependencies and try to support older macOS versions as best as I could.

[sciurius]

Looks great already!
Stupid question of a typical non-Mac user: How do I run it?

[Desbeers]

• Download the project
• Open the project file in Xcode.
• Change the signing certificate to your own.
• Build and run!

I assumed you have a Mac and Xcode installed.

Else, helaas-pindakaas... You need a Mac to build and run it...

Do you have a Mac? Since you provide a binary for macOS that was obvious to me...

[sciurius]

No, I do not have a Mac... I have a VBox with MacOS that I use to make the MacOS binary distributions, but it doesn't have Xcode. But if I can make binary distributions I assume you can?
Maybe start with the ChordPro dmg and add your stuff to it?

[Desbeers]

I can move your binary into the macOS package (after some homework) and build it.

Hoverer, that makes it mine, not yours.

That is not the goal. You should build it somehow because I don’t want to be a a new implantation :-)

[sciurius]

First step is to make it work and in such a shape that an average MacOS user will like it.

In an ideal situation all binary kits should be built centrally and automatically, but that isn't the case anyway. Kits for Debian and Fedora are built indepently. I don't know if GitHub can build MacOS kits, if so that would be an option.
For the time being it is perfectly acceptable to roll out a release (source) and that others (me included) build the binaries.

[Desbeers]

I’m unable to build the Mac dmg myself for now, it has too many missing packages to compile, wrong perl version etc... However, I just moved the precompiled ‘chordpro’, ‘libperl’ and ‘lib’ + ‘script’ folders from the official app into my source and the result is a self-containing app that seems to work well.

I don’t have an Apple developers account so I’m unable to make a pre-compiled app to share.

It would be great if somebody with a Mac can download the source and compiles it with Xcode so I know it’s working as I intended.

[sciurius]

Isn't it possible to add your app to the prebuilt dmg and use it as entry point instead of dndhandler?

I build the MacOS dmg with homebrew perl.

sudo brew install perl

Then unpack the ChordPro github stuff, go into that folder, and type

sudo cpanm --installdeps .

If you then go to the folder pp/macos, you should be able to run a 'make'.

[Desbeers]

Unfortunately, that still does not work... I can build from Git, and with cpan but the ‘make’ in pp/macos still complains about missing ‘wxWidgets’ even when I only do a make chordpro.

I tried to install ‘wxWidgets’ but again errors...

I’m well known with homebrew and make but not too much about perl.

Anyway, I gave that a rest for the moment and updated my wrapper to a very useful state.

• Select build-in themes
• Options to transpose and transcode
• All the benefits of a SwiftUI document application like opening multiple files, save with versioning support and as native as native can be on a Mac.

Main thing missing is the selection of custom files to use but I know my way around to do that. I’m well known with the sandbox restrictions and how to deal with them.

Code-signing is a different issue. The current wrapper is not signed so the familiar “the developer could not be verified” pops up. Ok, I thought that was no big deal. I compile a package, strip my useless free singing (that only works on my mac) and call it the day. Unfortunately, I found out that arm-binaries for the Mac must be signed wit a valid and paid developer account, else it will simply not run.

So, there are only three options:

• Make an intel only binary but that will soon not work on modern arm Macs I’m afraid.
• Find somebody with a paid developer account who is willing to compile and sign the binary in Xcode. The good thing is, then it can be released in the AppStore as well in case you are interested in that. I’m not, to be honest, all my Mac coding is just for fun and I only provide source code on my GitHub.
• Last option is to top distributing a compiled macOS wrapper...

So, lets give it a thought and meanwhile it would be nice if we can find another Mac user in the community who like to try my new wrapper. It looks and works very well for me!

[Desbeers]

[sciurius]

I can build from Git,

Just to make sure: are you using the dev branch?

and with cpan but the ‘make’ in pp/macos still complains about missing ‘wxWidgets’ even when I only do a make chordpro.

In the makefile there is TARGET := wxchordpro. I think you must change that to TARGET := chordpro.

[sciurius]

Unfortunately, I found out that arm-binaries for the Mac must be signed wit a valid and paid developer account, else it will simply not run.

Does that apply to dmg as well?

[sciurius]

Let's stay optimistic and get technical. If you take a look at pp/linux/ppl.c you'll see that it is a rather trival program that sets up a couple of things and then calls the main entry point in libperl.so. Do you think that could be done directly from your SwiftUI program?

[Desbeers]

Let’s answer your pervious questions first.

Just to make sure: are you using the dev branch?

Yes.

In the makefile there is TARGET := wxchordpro. I think you must change that to TARGET := chordpro.

It makes no difference.

Does that apply to dmg as well?

Yes. It is just a nice packaging of the application. Same rules apply. The application in the dmg must be code signed for arm Macs.

Now lets get technical as well:

I don’t understand your last suggestion. I don’t care how a chordpro binary is created (in a technical way). All my SwiftUI wrapper is doing is calling the binary in a Swift Process() Task together with its arguments. It is very simple.

I just copied the binary, together with its requirements, from the current package into a folder inside my source to run in a Task. Reason for that is sandboxing. I can run it from a homebrew installed chordpro in exactly the same way. Just call it from a different location. That cannot be sandboxed (it is outside the package) and needs additional installations from the user.

I wrote a ‘Book Creation App’ in exactly the same way that is using Pandoc and a full Latex install. All must be installed independent with homebrew or another package manager on macOS. It is calling a very smart make to create the books so I know how to write it.

Good enough for my home projects but not for chordpro.

The self-contained binary must be part of the package. And that is were the bigger problem is right now.

• I can’t build a ‘command line’ only binary with make chordpro in the ‘pp/macos’ folder (or any of the other targets). It is a bit out of my knowledge to fix this. You can, because you can build it and move it into the package. I might be wrong but it looks like ‘wgWidgets` is all over the place, even when not needed.

Once a binary can be created, I can write an new make that builds the chordpro binary, move it into the SwiftUI wrapper ‘Bin’ directory source code (that the application itself does not care about) and create the Mac App with xcodebuild. That is part of my knowledge ;-)

We are getting close!

This is much more challenging than I thought but does not discourage me!

The SwiftUI wrapper itself is a non-issue for me, wrote it in a couple of hours with joy and any additional options are simple to implement. The foundation is in place. Settings will be preserved, build-in templates and notations are not hard-coded but directly from the source so the wrapper is very stable.

[sciurius]

I've checked in new version of the pp/macos/Makefile. This should be able to build cli-only with TARGET=chordpro.
Can you give it a try?

[sciurius]

The application in the dmg must be code signed for arm Macs.

So unless we find someone to build/sign this will be the end of ChordPro for MacOS?

I've been told that intel binaries will still run on arm Macs (but you'll get a warning).

The best option would be to form an MacOS Special Interest Group within the ChordPro community. Unfortunately, most MacOS users on the list are not responsive to support questions (you being the god-sent exception).

[Desbeers]

I've checked in new version of the pp/macos/Makefile. This should be able to build cli-only with TARGET=chordpro. Can you give it a try?

Closer, but still complaining about missing packages. I think that is because the building is using the system perl and not the one from homebrew even tho it is in front of my $PATH. I will investigate....

[Desbeers]

The application in the dmg must be code signed for arm Macs.

So unless we find someone to build/sign this will be the end of ChordPro for MacOS?

I've been told that intel binaries will still run on arm Macs (but you'll get a warning).

The best option would be to form an MacOS Special Interest Group within the ChordPro community. Unfortunately, most MacOS users on the list are not responsive to support questions (you being the god-sent exception).

Correct, intel builds will still run on arm Macs. Unsigned universal builds will not.

But, good news!

I found out how to build a intel-only version, stripped the signing, uploaded it to GitHub, created a completely fresh account on my Mac, downloaded the ZIP, 2 times right-click to open and it works!

Clumsy, but progress!

So, I have a test build available:

https://github.com/Desbeers/ChordProMac/tree/main/TestBuild

[sciurius]

Poor me....

Is that something you can fix, or do I need a new MacOS?

[Desbeers]

Is that something you can fix, or do I need a new MacOS?

I’m afraid you need a new macOS... SwiftUI is very immature on older versions than 13.

MacOS 10.15 only supports SwiftUI version 1 and that was really horrible...

I suggest to keep the current wrapper around for older Macs and just add mine as an addition for never versions.

[sciurius]

No problem, I need to maintain the current Wx wrapper anyway, for Linux and Windows.
It's just that I'm going to be the last person to be able to admire your work :( .

[sciurius]

Do you need additional modifications from my side, to make it easier for you to build?

[Desbeers]

No problem, I need to maintain the current Wx wrapper anyway, for Linux and Windows.

Poor Linux and Windows users. My wrapper will turn ChordPro for macOS from the Ugly Duck into the most beautiful Swan of the Family, hahaha!!

It's just that I'm going to be the last person to be able to admire your work :( .

A managed to get the minimum version down to macOS 12 (not committed yet). Slightly less beautiful but a good compromise to support at least the last three versions and fundamentally the same.

I can’t go any lower... Sorry!

Do you need additional modifications from my side, to make it easier for you to build?

Thanks, but not for now. It simply does not build the command line version on my Mac. I just keep your latest bin in my source and see how to fix that later.

My TODO list:

• Complete the macOS 12 version and commit.
• Write a make to build the package from the command-line with xcodebuild for Intel without any code-signing.
• Make new (party automated) test-builds available.
• Test, test, test!

And then...

• Then (meanwhile)... find out how to compile the bin stuff myself. I might need your help for that again.
• Clone your source and stuff my stuff into pp/macosswift for example.
• Update the make file to build the whole SwiftUI app, including the self-contained bin from your source.
• Send a PR
• Celebrate!!!!

All doable. The fact that I have a public available app now proves that it can be done!

[sciurius]

It simply does not build the command line version on my Mac

Can you do a fresh checkout from git,

cd ChordPro
cpanm --installdeps .
cd pp/macos
make

and send me the complete log?

[Desbeers]

Last login: Wed May 29 20:15:48 on ttys003
Desbeers@UberBook chordpro-dev % cpanm --installdeps .
Can't write to cpanm home '/Users/Desbeers/.cpanm': You should fix it with chown/chmod first.
Desbeers@UberBook chordpro-dev % sudo cpanm --installdeps .
Password:
--> Working on .
Configuring /Users/Desbeers/Downloads/chordpro-dev ... OK
<== Installed dependencies for .. Finishing.
Desbeers@UberBook chordpro-dev % cd pp/macos
Desbeers@UberBook macos % make
rm -f *.pp.deps *~ chordpro wxchordpro
rm -fr build
rm -fr ChordPro.app
perl wxchordpro_pp.pl > wxchordpro.pp
pp --output=wxchordpro @wxchordpro.pp ../../script/wxchordpro.pl
/usr/bin/pp5.34: Shared library (option --link) doesn't exist: /usr/local/lib/libpng16.16.dylib at /System/Library/Perl/Extras/5.34/PAR/Packer.pm line 1216.
make: *** [wxchordpro] Error 2
Desbeers@UberBook macos % make chordpro
pp --output=chordpro @chordpro.pp ../../script/chordpro.pl
/usr/bin/pp5.34: Cannot find module PDF/API2.pm (specified with -M)
make: *** [chordpro] Error 2
Desbeers@UberBook macos %

[terevos]

I get the same exact error on my Mac. (M2 Pro on Sonoma 14.4.1)

[Desbeers]

I get the same exact error on my Mac. (M2 Pro on Sonoma 14.4.1)

Welcome to debug!

[sciurius]

Het commando voor cli is make TARGET=chordpro .

[terevos]

That command results in the same error. I'm going to try out perlbrew and see if I have any luck with that.

Homebrew's perl should not be trying to pull cpan modules from the system, I don't think. And I made sure that I have homebrew's libpng installed. (I'm not a perl guru, though)

[Desbeers]

I wanted to tweak the spacing of the Songbook a bit with wxGlade, but I can’t open the file. wxGlade is main from GitHub and I can open all the other .wxg files.

Any idea?

[sciurius]

File has changed dialog

Fixed.

‘New Song’ saving

Fixed.

Create config

Improved.

[sciurius]

Any idea?

Try wxglade --config dot.wxglade ?

[Desbeers]

Try wxglade --config dot.wxglade ?

Error that there was no --config option but selecting the ChordPro widgets in the Preference of wxGlade as 'local widgets path' did the trick. Working!

[sciurius]

Ah, yes. See GNUmakefile in the Wx folder

wxglade --generate-code=perl --use-config=dot.wxglade/wxgladerc
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Desbeers]

I've just updated from dev and now with _191 I cannot open the Settings:

Can't call method "SetSelection" on an undefined value at /Applications/ChordPro.app/Contents/MacOS/script/../lib/ChordPro/Wx/SettingsDialog.pm line 304.

[sciurius]

Fixed it, but I hadn't pushed the commit. Should work now.
BTW: the theme settings are not functional. Working on it.

[Desbeers]

Build a fresh _194 on macOS and Fedora. A quick look showed me all is fine. Give me a few hours for bug-hunting and if no major things, I'll send you an ARM build.

[Desbeers]

(started with fresh install and removed the prefs file; ChordPro build with the enhanced wxPerl)

Dark Mode

• Follows the system (switching from System Settings). Good!
• Setting it to Dark (in ChordPro Settings) directly switched to the selection (nice!) and keeps it dark (ignoring System Settings). Good!
• Same when selected Light. Good!
• When going back to System, the system was followed again. Good!

I did get a crash one time; but I’m unable to reproduce it. It crashed on startup (once, but both on macOS and Fedora) and when opening again, all was fine again.

Message in the Terminal:

Too few arguments for subroutine 'ChordPro::Wx::SettingsDialog::OnThemeChanged' (got 0; expected 1) at /home/desbeers/GitHub/Clones/chordpro/pp/linux/build/script/../lib/ChordPro/Wx/SettingsDialog.pm line 609.

All in all. Great!

New config creating

• The ‘new’ button works perfect! Both on macOS and Fedora. I like it very much I don’t have to add the ‘.json’ extension myself. Good!
• Just changing the selected name in the textfield to a new one pops-up the dialog twice on macOS (but did create it). Maybe make this textfield read-only? Edge case...
• After creating the default-filled config (and didn’t change it) the Preview does not work anymore and there is a fatal error in the log:

Error: Can't use an undefined value as an ARRAY reference at /Applications/ChordPro.app/Contents/MacOS/script/../lib/ChordPro/Song.pm line 179.

Ooops, showstopper...

(I will update the existing relevant docs; ignoring this issue)

'electric' actions

• Typing a ] will look for a preceding chord name... Nice! Seems to work well. Good!
• Typing a :, space or } after what looks like the beginning of an abbreviated directive will expand it... Very (very!!) nice! Good!
• Enter before a } will insert after the brace. One of those things you don’t even notice (unless you now). Again very nice! (didn’t try the shortcut). Good!

Learning a new expression as well...

(I’ll leave the docs to others for now)

Songbook

Briefly tested it; all seems (still) fine. Tried the ’standard cover page’ as well my custom cover.

(with all my excitement about the highlighted editor and inline preview I almost forgot about this great addition)

Rearranging the songs works fine as well. All good!

Minor thing, the ‘dialog’ when creating the Preview does jump in width. It showing full path while scanning its files at start or so... No big deal.

Creating new songs

• The ‘saving’ after ‘create’ (without altering it) is fixed. Good!
• Opening the ‘example song’ does show the old behaviour; I cannot save it on creation. Edge case...

Settings

• Just randomly changed settings (I don’t think all settings, but most) and all works well. Good!

Dialogs

• ’Short’ file-names, nice! Good!

So...

Almost good to go! It is just the ‘created new config’ that I see as a showstopper; especially because that is the door to the real power of ChordPro’s gorgeous PDF creation.

[sciurius]

I did get a crash one time; but I’m unable to reproduce it.

Probably when you switched theme at the system level while chordpro was running. Fixed.

Maybe make this textfield read-only?

Done. The only reason why it was editable was to be able to create a new config.

Error: Can't use an undefined value as an ARRAY reference

It wrote the wrong config. Fixed.

the ‘dialog’ when creating the Preview does jump in width.

Standard behaviour, unfortunately.

Opening the ‘example song’ does show the old behaviour; I cannot save it on creation.

Cute. It is not modified but still you want a save dialog. Fixed.

Fixes are in 6.060_199.

[Desbeers]

(My Window Maker can't wait to open its ChordPro songs)

[sciurius]

I almost forgot about this great addition

The longer I think about it (and the more I use it) I think the songbook builder should be the central starting point. 'Getting Started' could be something similar to

• Start ChordPro
• Have some songs already? Click Songbook and navigate to the folder with the songs.
• Now you can inspect and edit the individual songs, preview each song
• Back to the songbook builder for more.
• When satisfied, create a songbook.
• No songs? Click New to create your first ChordPro song. Or click Example and play around.

Feels natural to me.

[Desbeers]

I like this idea very much!

The current Getting Started is a mixture of just some random subjects.

I can split it into separate pages, so we get:

• Getting started (general)
  • Link to GUI page (with your suggested structure)
  • Link to CLI page

Don’t really know where to put ‘Legacy ASCII input format` yet. Is it really legacy? Maybe for ChordPro (I don’t know) but it is a common format. See ultimate-guitar for example.

It is just ‘Chords over Lyrics’ notation. So, I think just create a separate page for it and take it from there...

No time today but tomorrow I can just ‘move stuff’ around and give the Songbook some more (deserved) love on its own (GUI) page. Leave it up to me.

Then some for you: It is not obvious in the Songbook GUI that you can double-click a song to edit it and can come back to the songbook. A nice ‘notification’ (like for the custom library) when starting a new songbook that you can ‘double-click’ it to edit it and can come back. Simple but effective; the GUI should be self-explanatory.

[sciurius]

Or something simple,

[sciurius]

Don’t really know where to put ‘Legacy ASCII input format` yet. Is it really legacy? Maybe for ChordPro (I don’t know) but it is a common format. See ultimate-guitar for example.

I think you mostly nailed it by describing it as ‘Chords over Lyrics’ notation. It is important that users recognize the format and know that ChordPro can deal with it.

[sciurius]

Suggestions to further emphasize the role of the songbook:

• Move "Create a Songbook" to the top on the start page.
• On the other pages, split menu New into Main Page and New.
• Add Songbook menu to Tasks?

[sciurius]

On macOS, can you visit a folder in the Finder and then 'open ChordPro here' (starting ChordPro with the folder as argument)?

[Desbeers]

Or something simple,

Oh yes, simple and clear. No need to make it more fancy.

On macOS, can you visit a folder in the Finder and then 'open ChordPro here' (starting ChordPro with the folder as argument)?

Currently, no. The dndhander is still a hack. The swift version fixed the Catalina dialog issue but it is still not as is should be. You can open a song from the Finder while ChordPro did not start yet but you cannot open another song from the Finder while ChordPro is open. I can add even more hacks to get this working (one time) with a folder but I would like to fix the root problem first and then maybe extent it.

(On my Fedora, I can open many ChordPro windows, on macOS I cannot)

---

Ok, I let this songbook idea boil for a while this evening and the main purpose of the GUI/CLI is not to be an implementation but the reference implementation of the ChordPro format. Too much focus on the Songbook takes away the focus of its reference implementation of the format.

ChordPro is not a library utility, it is a file format.

A challenge to find a balance. Lets stay focused. Leave the GUI as it for now please.

PR later tomorrow...

[Desbeers]

Well, gave it a shot to focus more on the songbook. Writing documentation is not my strongest point but I think it is already better like this...

[Desbeers]

And so goes the circle around. The SwiftUI wrapper for ChordPro was basically a stripped-down version of my Chord Provider. Now Chord Provider incorporates the CLI ChordPro :-)

It was simple to do. Both applications had most in common, took me about an hour or so...

Main reason is I like to boil ideas in Swift because I don’t have to think how to it programatically, I just have to get ideas. My comfort-zone.

I think the current documentation is good enough for now. So is my (PR) landing page. All the remaining issues are wording related and I leave that to others.

I don’t like to write documentation. I updated the current pages because that was needed for a next release. I didn’t enjoy it and you correctly gave me a warning in that other issue.

Still aim for a Christmas Release

Shall we close this issue on the next release?

That will be my Christmas present!

Because it was my most challenging journey of 2024!

[sciurius]

Great. Your challenge for 2025: embed ChordPro natively in Swift ☺.

Thanks a lot, I'll take over from here.

[Desbeers]

Your challenge for 2025: embed ChordPro natively in Swift ☺

Nah, my first challenge concerning ChordPro for 2025 is get the dndwrapper as it should be. So that means I have to get my hands dirty on Perl and C++. I’ll leave my Swift project for relaxing moments ☺

Then I want to have more easy config stuff into wxChordPro, together with some more fancy build-in templates. This not just by suggestions but with PR’s. That is why I back-ported ChordProMac to Chord Provider. My playground.

Meanwhile I keep playing with my ’structured’ parsing and ‘document cleaning’ but that is very opinionated stuff and maybe for another day.

So enough to learn and contribute again next year!

When you need ARM builds for macOS, just let me know!

[Desbeers]

Maybe a bit too cheesy ☺

Release.chordpro.txt
Release.pdf

[sciurius]

LOL!

[sciurius]

I've branched R6.070.RC1 for prerelease. Can you check it out and make an ARM image?

[Desbeers]

I’ve downloaded the source from the pre-release page and build an ARM version; so it should exactly be the same.

Tested the install on a ‘clean’ macOS VM and all seems to work fine; including the installation script.

I mailed you a link.

[Desbeers]

Ok, completely useless and just eye-candy, but I like to port the macOS Finder ‘Thumbnail Creation’ that is part of my Chord Provider to ChordPro. Because why not?

It is just looking into the document for a {title} directive and using it as a badge. It is completely independent of the actual application so easy to do.

        var extensionBadge = "ChordPro"
        let title = /{title(.+?)}/
        if let result = try? title.firstMatch(in: fileContents) {
            extensionBadge = String(result.1).replacingOccurrences(of: ":", with: "").trimmingCharacters(in: .whitespaces)
        }

The dndwrapper issue is higher on my list but I enjoy this details stuff. It is like the red dot on macOS; just details. It does not make the application really better but it makes it feels better.

I’ve updated my README to make my intensions clear. Chord Provider is my hobby project for almost 5 years but I’m devoted to the official implementation.

[sciurius]

I've branched R6.070.RC2 for prerelease. Can you check it out (or use the tar.gz from the release page) and make an ARM image?

[Desbeers]

Link in your mail!

(we have to improve this workflow ☺ )

[Desbeers]

The biggest philosophical difference between ChordPro and my Chord Provider is that my implementation is a screen viewer first and foremost. ChordPro is first and foremost an Editor to create PDF’s. Very different intensions.

I would like an existing file to be opened in a preview only by default with an option to edit it. Maybe just an additional Edit button like the Songbook back button? So the editor itself is hidden by default for existing files.

My workflow:

• I open an existing ChordPro file because I want to play that song. Editing only when needed. I want to see the song.
• I create a new song and need the editor and preview to make it to my liking.

(to be discussed for a next release ☺)