Add Per Display Configuration#612
Conversation
…Action and DisplaySettingsManager
…Name property to NSScreen extension
|
As I am thinking more about it, maybe it is better to move the whole general settings into per display! TODO: Name of displays should be taken from OS. |
|
Thanks for the PR! I haven't had time to look in-depth into this yet, but will be sure to when I get the chance. From looking at the screenshots, I'm not sure about having an entire settings pane just for display settings. I want to keep the interface as streamlined as possible, and I feel like this might end up overcomplicating things, especially for new users. I'll be thinking about some other options. Please discuss any ideas you may have with me before going ahead with further changes. Also, be aware that I've made a lot of changes to support macOS Tahoe that haven't been merged into |
|
Hey, Thanks for sharing your thoughts. About Display, I was thinking of including more options (like widescreen monitor options). In that way, adding a whole new menu would be beneficial in the future. If you don't want to add those potential options, it is clearly better to not add another menu and handle it other ways. |
|
Exciting for us heavy multi-monitor users!!! |
|
For me, this is THE feature that this little gem is missing! |
|
Pls integrate into main branch! So many of us are waiting for this |
|
This is THE feature that ice has been lacking for a long time, I need it so much. |
|
So excited to see this moving forward :) |
|
How to recreate the build file? it is expired in github and not available anymore :( |
|
@pourmand1376 I'm a bit lost. You developed this highly requested feature several months ago, but I still don't see it even in the newest beta version. Is this still pending merge? |
|
Hi @marcgarciamarti. Yes. That's developed on my side. Seems like the developer hadn't had time to look into my PR. So, it's left for good. @jordanbaird. Can you please take a look at this PR sooner? |
Can't wait to see this on my computer!!! |
|
@pourmand1376 would you consider opening a PR against my fork for this? https://github.com/stonerl/Thaw |
Hi @stonerl, I'm currently busy and can't do another PR for some time. Thanks. |
|
Has been implemented in Thaw based on your PR AFAIK. |
|
Switching to Thaw! Thanks so much! Hopefully I can finally be free from Bartender that has been a bit funky for far too long. |
Extracted from upstream PR jordanbaird#612 (Per Display Configuration) by Amir Pourmand. Only the CI portion (.github/workflows/build-dmg.yml plus ExportOptions.plist) is taken — the feature code from jordanbaird#612 lands separately in a later commit. The workflow builds on macos-latest with latest-stable Xcode, archives without code signing, exports the .app, packages it into a DMG named after the git tag (or the commit SHA for non-tag builds), and uploads it as a workflow artifact. Triggers: push of a tag matching v*, or manual workflow_dispatch from the Actions tab. There is no push-to-branch trigger because we do not want every cherry-pick spinning up a 10-minute macOS runner. The exported app is unsigned and not notarized — we do not have an Apple Developer Program account. Users will need to right-click → Open or run `xattr -dr com.apple.quarantine /Applications/Ice.app` once. Original author retained as the per-file blame; the CI infrastructure contribution is credited to Amir Pourmand (@pourmand1376) in our release notes.
ROADMAP.md is the working engineering plan for the fork. Five phases: foundation (CI + Sparkle decision), Tahoe stability cherry-picks, upstream 0.12.0 merge, feature PRs (jordanbaird#612, jordanbaird#795, jordanbaird#941, jordanbaird#667), rebrand with UserDefaults migration, original heavy-user features. Each phase broken into sprints with concrete file:line targets, decision points, risk register, and a Gantt-style summary. docs/ICON_BRIEF.md is the design brief for the eventual Fire app icon (Balerion-inspired dragon eye on obsidian black with ember gradient, mirroring the existing Ice icon's squircle geometry in inverted temperature). Includes ready-to-use Midjourney and DALL-E prompts, required AppIcon.appiconset sizes, and rejection criteria. Also add .codegraph/ to .gitignore — the local symbol index database should not be committed.
The upstream PR jordanbaird#612 workflow uses xcodebuild -exportArchive with an ExportOptions.plist that sets signingStyle=automatic and leaves teamID empty. On a GitHub-hosted runner with no Apple Developer Program account in the keychain, that step fails — it tries to locate an automatic signing identity and finds none. Replace the entire export step with two lines: copy the unsigned Ice.app straight out of the xcarchive bundle, then ad-hoc sign it (`codesign --sign -`). The resulting app launches under Gatekeeper after the user removes the quarantine attribute or right-click → Open. This is the same shape of distribution all major unsigned macOS apps use (mas, balena-etcher in pre-notarization era, etc.) and matches what we plan to ship until we acquire an Apple Developer Program seat (tracked in ROADMAP.md Phase 0.1 "Decision point — Signing identity", recommendation: stay ad-hoc through 0.11.13-fire.* and re-evaluate at the Phase 4 rebrand boundary).
10 participants
Hi, I've added per display configuration to Ice!
You can take a look at my ice build here and install it.
My Big Screen:
My Mac Screen:
