-
Notifications
You must be signed in to change notification settings - Fork 43
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.
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
Nio on macOS: Mio, Part II #277
Nio on macOS: Mio, Part II #277
Conversation
This is a copy of the iOS one, which we should eventually fix. According to the names, most icons should probably get replaced w/ SF Symbols anyways.
The release one is still hardcoded, like on iOS.
Follow ups to the other patch.
I know that this isn't necessary, but a) it is now consistent with my other changes :-) b) I still thing it makes the intention clearer
Mio uses more SF icons already. Maybe iOS should too.
Mark `MarkdownText` as unavailable. This approach is wrong anyways as per discussion. The text fallback in Matrix messages is _just_ text, not Markdown. For rich display we need to parse the HTML and maybe generate an attributed String from that (or a View hierarchy).
Until we have a proper attributed text field, use the plain `TextField` for message editing. It ain't great, but works. Mark `AttributedText` unavailable on macOS. And fix a linter func length warning by copying the func, linters are just the best idea evar 🤦♀️
The macOS version looks a little different.
A few more modifications to make stuff look nice on macOS. This also introduces a Style enum in the app file, that should probably go elsewhere.
Make sure Mio always builds.
Hope that works.
Maybe we should just merge the two.
Fails w/ ❌ error: No signing certificate "Mac Development" found: No "Mac Development" signing certificate matching team ID "Z123456789" with a private key was found. (in target 'Mio' from project 'Nio') 7 Which exceeds my GH actions knowledge.
@@ -43,6 +53,47 @@ struct RecentRoomsView: View { | |||
rooms.filter {$0.room.summary.membership == .invite} | |||
} | |||
|
|||
#if os(macOS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth pulling the List
out into var roomsList: some View
and then having a single body
that was along these lines?
#if os(macOS)
roomsList
.macModifiers()
#else
roomsList
.iosModifiers()
#endif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They would need to be called .archSpecificModifiers()
and then have branches of that modifier. It is one way to do this if it only affects the modifiers.
RecentRoomsView
was the top-level container view, right? My suggestion is to split that out into separate files as they are most likely to diverge, not sure. Actually it is often more like "is it iPad or macOS, then use the more complex view, otherwise use a small mobile view, or a watch view, even smaller"
There is also this, which I've been toying around with in a different project: sindresorhus/swiftui#7 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, yes I was kind of meaning .macModifiers()
and .iosModifiers()
to be shorthand for the whole list of modifiers that are currently there. I was just about to reply to
Maybe the files should be split up per architecture instead of the sometimes relatively big
#if
's, not sure.
to say, yes, this seems to need some consideration as it's hard to follow those big #if
blocks.
Did you try |
Nope, but lets keep the CI thing out of this PR for now, it should go into a second. I'm already unhappy with myself that I even tried as part of this PR and produce a set of useless CI commits :-) |
Use a proper color for the message bubbles, as available via that static function.
This is really different and doesn't belong into this PR _at all_.
Is it best to leave the big |
I think we should leave them for this iteration, i didn’t want to touch the file structure (and risk xcode project merges) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In which case, looks good to me! 🎉
Great work! Just tried out the current build you offered for download, and found issue #279 which is Mac specific I believe. |
Prefs panel is the right place. Changing the accent color doesn't seem to do anything, though :-)
Do not wrap the form in a navigation view, put the create button into the toolbar, which surprisingly shows up proper in the sheet.
# Conflicts: # Nio/Conversations/RoomView.swift
This looks awesome! I'd love to merge this or is there anything still left open? |
If everyone is cool with it, this should be merged ASAP before the other work drifts apart too far. Afterwards we should also cleanup the files (i.e. split the views w/ bigger #if sections), but only if most of the changes are in, to avoid more merge conflicts. |
This primarily adds displaying content using
Text
and composing messages usingTextField
, on macOS. It also has a lot of adjustments to fix visual glitches on macOS. Maybe the files should be split up per architecture instead of the sometimes relatively big#if
's, not sure.The
Views
we don't have on macOS yet are marked as unavailable:MarkdownView
,AttributedText
. The latter we probably want to have, but it is a non-trivial effort to build a good richtext compose field (the one in Shrugs is a lot of code). The former should be dropped in both iOS and macOS and get replaced with the HTML body parsing.