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.

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

Merged
merged 19 commits into from
Mar 26, 2021

Conversation

helje5
Copy link
Contributor

@helje5 helje5 commented Mar 16, 2021

This primarily adds displaying content using Text and composing messages using TextField, 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.

helje5 added 13 commits March 16, 2021 11:45
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.
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)
Copy link
Member

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

Copy link
Contributor Author

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)

Copy link
Member

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.

@pixlwave
Copy link
Member

Did you try xcodebuild -scheme Mio build CODE_SIGN_IDENTITY="-" DEVELOPMENT_TEAM="" for the GitHub action? It succeeds locally for me.

@helje5
Copy link
Contributor Author

helje5 commented Mar 19, 2021

Did you try xcodebuild -scheme Mio build CODE_SIGN_IDENTITY="-" DEVELOPMENT_TEAM="" for the GitHub action? It succeeds locally for me.

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 :-)

helje5 added 2 commits March 19, 2021 13:02
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_.
@pixlwave
Copy link
Member

Is it best to leave the big #if blocks as they are for now and look at them once this is merged? I'm happy either way 😄

@helje5
Copy link
Contributor Author

helje5 commented Mar 19, 2021

Is it best to leave the big #if blocks as they are for now and look at them once this is merged? I'm happy either way 😄

I think we should leave them for this iteration, i didn’t want to touch the file structure (and risk xcode project merges)

Copy link
Member

@pixlwave pixlwave left a 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! 🎉

@MarcoZehe
Copy link

Great work! Just tried out the current build you offered for download, and found issue #279 which is Mac specific I believe.

helje5 added 4 commits March 20, 2021 12:29
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
@kiliankoe
Copy link
Member

This looks awesome! I'd love to merge this or is there anything still left open?

@helje5
Copy link
Contributor Author

helje5 commented Mar 26, 2021

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.

@kiliankoe kiliankoe merged commit 788ee9e into niochat:stable Mar 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants