Version 1 vs 8
Version 1 vs 8
Edits
Edits
- Edit by keithzg, Version 8
- Apr 1 2024 10:57 PM
- ·Home and End rebinding
- Edit by keithzg, Version 1
- Jul 5 2021 9:31 PM
- ·Initial page creation
Edit Older Version 1... | Edit Draft Version 8... |
Content Changes
Content Changes
## Packages
For a lot of its history, OSX (nowadays "macOS") was overly advertised as a user-friendly version of UNIX. This was of course always largely a lie, and none mores than in how it in fact lacks what all contemporary UNIX-derived OSes have had for decades: a package manager, where everything could just be installed and managed (ex. updated, removed, etc) from one interface.
Much like with #Windows, there are multiple attempts to implement such a thing in the absence of it in the base operating system. Notable ones you might consider using are:
* [[ https://www.macports.org | MacPorts ]], almost certainly the best one if I'm remembering correctly, full of the software you'd expect to have immediate access to on any Linux system
* [[ https://brew.sh | Brew ]], the brogrammer one and the one generally used for stuff that involves a bunch binaries or random forks of things.
## Running and packaging up Windows applications
https://github.com/vitor251093/wineskin was the way to create Wine app packages for #macOS. https://github.com/Gcenx/WineskinServer is a bunch hacks to make that viable on modern versions that have gutted 32-bit support.
## Home and End work wrong
Yeah, it's annoying, because they seem to generally do the same thing as PageUp and PageDown. I already have those keys!!!
As per random suggestions on the internet,
```
lang=bash
mkdir -p $HOME/Library/KeyBindings
echo '{
/* Remap Home / End keys to be correct */
"\UF729" = "moveToBeginningOfLine:"; /* Home */
"\UF72B" = "moveToEndOfLine:"; /* End */
"$\UF729" = "moveToBeginningOfLineAndModifySelection:"; /* Shift + Home */
"$\UF72B" = "moveToEndOfLineAndModifySelection:"; /* Shift + End */
"^\UF729" = "moveToBeginningOfDocument:"; /* Ctrl + Home */
"^\UF72B" = "moveToEndOfDocument:"; /* Ctrl + End */
"$^\UF729" = "moveToBeginningOfDocumentAndModifySelection:"; /* Shift + Ctrl + Home */
"$^\UF72B" = "moveToEndOfDocumentAndModifySelection:"; /* Shift + Ctrl + End */
}' > $HOME/Library/KeyBindings/DefaultKeyBinding.dict
```
## Packages
For a lot of its history, OSX (nowadays "macOS") was overly advertised as a user-friendly version of UNIX. This was of course always largely a lie, and none mores than in how it in fact lacks what all contemporary UNIX-derived OSes have had for decades: a package manager, where everything could just be installed and managed (ex. updated, removed, etc) from one interface.
Much like with #Windows, there are multiple attempts to implement such a thing in the absence of it in the base operating system. Notable ones you might consider using are:
* [[ https://www.macports.org | MacPorts ]], the longtime leader of the pack full of the software you'd expect to have immediate access to on any Linux system
* [[ https://brew.sh | Brew ]], which is kindof the brogrammer one, but has an advantage in that it is also available for Linux
* [[ https://www.finkproject.org/ | Fink ]], which back in the day had way more than MacPorts, and wisely just uses `apt` and .deb packages under the hood rather than reinventing the wheel, unfortunately it seems to have fallen behind Apple's brutal OS update treadmill
* [[ https://community.kde.org/Craft | KDE's Craft ]], a meta-build system you can use to compile any KDE project (that has been ported enough to MacOS at least)
## Packaging up Windows applications
### Using Wineskin
https://github.com/vitor251093/wineskin was the way to create Wine app packages for #macOS. https://github.com/Gcenx/WineskinServer is a bunch hacks to make that viable on modern versions that have gutted 32-bit support.
Vexingly, [[ http://wineskin.urgesoftware.com/ | the original project page ]] seems to have died, and in true Mac developer fashion the forks didn't bother with any documentation on how to actually //use// the damn thing. The original project's documentation is at least [[ https://web.archive.org/web/20140706023357/http://wineskin.urgesoftware.com/tiki-index.php?page=Manual | available at archive.org]].
Salient steps are basically,
1. Run the Wineskin app
2. Get it to auto-update the runtimes and such
3. Create a new package by clicking the {nav Create New Blank Wrapper} button
4. It'll give you the option to see the new wrapper in Finder, which will be a `.app` file in probably `~/Application/Wineskin`.
5. //Inside// that .app is {nav Wineskin.app}, which is the setup utility and also runs by default if you haven't run it yet. You can run that to package stuff into the `.app` you created, as well as configure other aspects like the icon.
### Using Winebottler
Alternatively, one could perhaps use https://winebottler.kronenberg.org
### Uhh that all seems complicated can't I just run things?
I mean maybe, [[ https://www.playonmac.com/en/download.html | PlayOnMac ]] might Just Work.
## Okay, now I have a .app file that's actually a folder, but they usually come as .dmg files
Yeah, both because then they're single files and because OSX traditionally took the approach of them being self contained to the point of there being no such thing as an installer, the traditional way of distributing .app folders for Macs has been to put them inside a .dmg disk image that contains two things, the .app folder and a symlink to /Applications so people can click-drag the .app folder into their Applications folder. (And then run it and pin it forever to the dock until it's tiny as hell, from what I've observed in the wild, but anyways.)
https://gist.github.com/jadeatucker/5382343 seems to be a reasonable enough explanation of creating a .dmg file manually, and https://github.com/create-dmg/create-dmg is a script for creating such images and includes a few more alternatives at the end of its readme.
## Running the results
Whatever method you use, you may want to note [[ https://support.apple.com/en-ca/guide/mac-help/mh40616/mac | the official instructions for running unsigned apps ]].
Downloads will likely have to have some attributes cleared via something along the lines of `xattr -c ~/Downloads/among-us_v71_macos-winewrapped.app` or perhaps `xattr -drs com.apple.quarantine ~/yaddayadda`
## Home and End work wrong
Yeah, it's annoying, because they seem to generally do the same thing as PageUp and PageDown. I already have those keys!!!
As per random suggestions on the internet,
```
lang=bash
mkdir -p $HOME/Library/KeyBindings
echo '{
/* Remap Home / End keys to be correct */
"\UF729" = "moveToBeginningOfLine:"; /* Home */
"\UF72B" = "moveToEndOfLine:"; /* End */
"$\UF729" = "moveToBeginningOfLineAndModifySelection:"; /* Shift + Home */
"$\UF72B" = "moveToEndOfLineAndModifySelection:"; /* Shift + End */
"^\UF729" = "moveToBeginningOfDocument:"; /* Ctrl + Home */
"^\UF72B" = "moveToEndOfDocument:"; /* Ctrl + End */
"$^\UF729" = "moveToBeginningOfDocumentAndModifySelection:"; /* Shift + Ctrl + Home */
"$^\UF72B" = "moveToEndOfDocumentAndModifySelection:"; /* Shift + Ctrl + End */
}' > $HOME/Library/KeyBindings/DefaultKeyBinding.dict
```
## Packages
For a lot of its history, OSX (nowadays "macOS") was overly advertised as a user-friendly version of UNIX. This was of course always largely a lie, and none mores than in how it in fact lacks what all contemporary UNIX-derived OSes have had for decades: a package manager, where everything could just be installed and managed (ex. updated, removed, etc) from one interface.
Much like with #Windows, there are multiple attempts to implement such a thing in the absence of it in the base operating system. Notable ones you might consider using are:
* [[ https://www.macports.org | MacPorts ]], almost certainly the best one if I'm remembering correctlythe longtime leader of the pack full of the software you'd expect to have immediate access to on any Linux system
* [[ https://brew.sh | Brew ]], which is kindof the brogrammer one, but has an advantage in that it is also available for Linux
* [[ https://www.finkproject.org/ | Fink ]], which back in the day had way more than MacPorts, and wisely just uses `apt` and .deb packages under the hood rather than reinventing the wheel, full of the software you'd expectunfortunately it seems to have immediate access to on any Linux systemfallen behind Apple's brutal OS update treadmill
* [[ https://brew.sh | Brewcommunity.kde.org/Craft | KDE's Craft ]], the brogrammer one and the one generally used for stuff a meta-build system you can use to compile any KDE project (that involves a bunch binaries or random forks of things.has been ported enough to MacOS at least)
## Running and p## Packaging up Windows applicationsns
### Using Wineskin
https://github.com/vitor251093/wineskin was the way to create Wine app packages for #macOS. https://github.com/Gcenx/WineskinServer is a bunch hacks to make that viable on modern versions that have gutted 32-bit support.
Vexingly, [[ http://wineskin.urgesoftware.com/ | the original project page ]] seems to have died, and in true Mac developer fashion the forks didn't bother with any documentation on how to actually //use// the damn thing. The original project's documentation is at least [[ https://web.archive.org/web/20140706023357/http://wineskin.urgesoftware.com/tiki-index.php?page=Manual | available at archive.org]].
Salient steps are basically,
1. Run the Wineskin app
2. Get it to auto-update the runtimes and such
3. Create a new package by clicking the {nav Create New Blank Wrapper} button
4. It'll give you the option to see the new wrapper in Finder, which will be a `.app` file in probably `~/Application/Wineskin`.
5. //Inside// that .app is {nav Wineskin.app}, which is the setup utility and also runs by default if you haven't run it yet. You can run that to package stuff into the `.app` you created, as well as configure other aspects like the icon.
### Using Winebottler
Alternatively, one could perhaps use https://winebottler.kronenberg.org
### Uhh that all seems complicated can't I just run things?
I mean maybe, [[ https://www.playonmac.com/en/download.html | PlayOnMac ]] might Just Work.
## Okay, now I have a .app file that's actually a folder, but they usually come as .dmg files
Yeah, both because then they're single files and because OSX traditionally took the approach of them being self contained to the point of there being no such thing as an installer, the traditional way of distributing .app folders for Macs has been to put them inside a .dmg disk image that contains two things, the .app folder and a symlink to /Applications so people can click-drag the .app folder into their Applications folder. (And then run it and pin it forever to the dock until it's tiny as hell, from what I've observed in the wild, but anyways.)
https://gist.github.com/jadeatucker/5382343 seems to be a reasonable enough explanation of creating a .dmg file manually, and https://github.com/create-dmg/create-dmg is a script for creating such images and includes a few more alternatives at the end of its readme.
## Running the results
Whatever method you use, you may want to note [[ https://support.apple.com/en-ca/guide/mac-help/mh40616/mac | the official instructions for running unsigned apps ]].
Downloads will likely have to have some attributes cleared via something along the lines of `xattr -c ~/Downloads/among-us_v71_macos-winewrapped.app` or perhaps `xattr -drs com.apple.quarantine ~/yaddayadda`