Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: update Acceptable Formula for options/guis #6016

Merged
merged 2 commits into from Apr 15, 2019
Merged

docs: update Acceptable Formula for options/guis #6016

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6748b1e
docs: update Acceptable Formula for options/guis
jonchang Apr 15, 2019
eeecb62
Update docs/Acceptable-Formulae.md
claui Apr 15, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/Acceptable-Formulae.md
View file
Open in desktop
Expand Up @@ -60,7 +60,7 @@ Don’t make your formula build an `.app` (native macOS Application); we
don’t want those things in Homebrew. Encourage upstream projects to build and support a `.app` that can be distributed by [homebrew/cask](https://github.com/Homebrew/homebrew-cask) (and used without it, too).

### Stuff that builds a GUI by default (but doesn't have to)
Make it build a command-line tool or a library by default and, if the GUI is useful and would be widely used, add an option to build the GUI. Don't offer an option for multiple GUI backends, e.g. X11 is a bad user experience for GUIs on macOS.
Make it build a command-line tool or a library by default and, if the GUI is useful and would be widely used, also build the GUI. Don’t build X11/XQuartz GUIs as they are a bad user experience on macOS.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree with this, unfortunately. I think we shouldn't build GUIs in general. If that's too controversial I think adding .app GUIs to the list would be a good call.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MikeMcQuaid At the very least, we shouldn’t generally reject a GUI as long as it’s meant to pop up as a side effect of executing the CLI tool.

Examples for that would be a diff/merge tool or a PIN entry dialog.

Not sure if that’s what the last part of your comment meant. I feel that rejecting any GUI would be too restrictive.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was more saying if a GUI can be optionally disabled and the formula is still useful without it: we should probably do so (or, maybe more specifically, if it adds any meaningful size/dependencies/time to compilation/runtime). We should not build .apps at all because we don't have brew linkapps and in general for all these cases The Right Way to do GUIs on macOS is to ship a auto-updating, relocatable .app binary (in the app store or with e.g. Sparkle) in Cask.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MikeMcQuaid That helped clear it up. In other words: disable GUI if the program still makes sense that way. Reject the formula if GUI would be too heavy (or if it’s an app). Otherwise, accept formula with GUI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@claui Yup, exactly. Any chance you could submit another PR?


### Stuff that doesn't build with the latest, stable Xcode's Clang
Clang is the default C/C++ compiler on macOS (and has been for a long time). Software that doesn't build with it hasn't been adequately ported to macOS.
Expand Down