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

Use element home screen to create new chats by default #38

Closed
wants to merge 39 commits into from

Conversation

aofn
Copy link
Member

@aofn aofn commented Jul 27, 2023

Displays elements home screen by default on desktop browsers and allows toggling on mobile view.
Allowing users to create DM's and group chats.

pages/chat/[[...roomId]].js Fixed Show fixed Hide fixed
pages/chat/[[...roomId]].js Fixed Show fixed Hide fixed
pages/chat/[[...roomId]].js Fixed Show fixed Hide fixed
Marcel added 5 commits August 15, 2023 13:40
…e. remove submenu dropdown and replace it with onClick function making use of elements home screen. add css rules to make modal view from element usable on mobile
@aofn aofn marked this pull request as ready for review August 15, 2023 11:50
Copy link
Member

@fnwbr fnwbr left a comment

Choose a reason for hiding this comment

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

Quick question before going into details of the code changes: Can we not make this happen with CSS media queries only?

Detecting the device type with JS is something we never did in any previous React applicatio (and I have a feeling that we never should do), when we have the option to change things with CSS only.

) }

{ (deviceType !== 'mobile' || (deviceType === 'mobile' && roomId) || (deviceType === 'mobile' && !isRoomListVisible)) && <IframeLayout.IframeWrapper>
<IframeLayout.IframeHeader>
Copy link
Member

Choose a reason for hiding this comment

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

I think we don't want the <IframeLayout.IframeHeader> component in /chat anymore... it looks like this now:
Screenshot 2023-08-16 at 15-11-42 _spaces

... with two headers. When one is just enough.

Maybe check out what /chat looks like on main once more...

@andirueckel andirueckel marked this pull request as draft September 20, 2023 15:32
@aofn
Copy link
Member Author

aofn commented Nov 28, 2023

image not sure why this is happening. this is also already happening in main

@aofn aofn requested a review from fnwbr November 30, 2023 13:04
@aofn aofn marked this pull request as ready for review November 30, 2023 13:05
# Conflicts:
#	lib/auth/MatrixAuthProvider.js
#	pages/chat/[[...roomId]].js
Copy link
Member

@fnwbr fnwbr left a comment

Choose a reason for hiding this comment

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

@aofn There are a few things that I can use your help on. I've left comments on the diff.

* @returns {Promise<Object>} A promise that resolves to the created room or space.
* @throws {Error} If there was an error creating the room or space.
*/
async createRoom(name, isSpace, topic, joinRule, type, template, parentId) {
async createRoom(name, isSpace, topic, joinRule, type, template, parentId, application, visibility, historyVisible, encrypted) {
Copy link
Member

Choose a reason for hiding this comment

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

Where are we making use of any of these new parameters?
If we don't use them, let's not add them.

I guess this is a leftover from some previous concepts?

@@ -169,7 +180,8 @@ class MatrixAuthProvider {
const medienhausMetaEvent = {
type: type,
template: template,
version: '0.4',
application: application,
Copy link
Member

Choose a reason for hiding this comment

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

What's the difference between template and application?

At the same time, like I said above: I think we don't actually make use of this new "application" parameter anywhere. So let's remove it again?

<ServiceTable>
<ServiceTable.Body>
{ otherRooms && otherRooms.map((room) => {
return <ServiceTable key={room.roomId}><SidebarListEntry key={room.roomId} room={room} selected={room.roomId === roomId} /></ServiceTable>;
Copy link
Member

Choose a reason for hiding this comment

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

🤔

A <ServiceTable> inside of a <ServiceTable> (line 251)?
This results in this double-border again:

image

<DefaultLayout.IframeHeaderButtonWrapper>
{ roomId && <>
<CopyToClipboard text={roomId} />
<TextButton title={t('Leave room and remove from my library')} onClick={() => handleLeave(roomId)}>
Copy link
Member

Choose a reason for hiding this comment

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

  1. Missing translation
  2. One does not really remove a chat from a library, or? This sounds off to me...

The style hack is needed because setting 'display' to 'none' creates an error.
Element performs a few compatability checks before onLoaded fires.
Therefore, Element throws an error, saying the current browser is not supported.
Setting the height to 0px centers the loading spinner before the iframe is ready.
Copy link
Member

Choose a reason for hiding this comment

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

Sorry, but I don't understand any of this.
Yes, Element can take quite a while to load at times. Especially when on a bad connection.

But I don't understand what any of this is there for; especially do I not see any loading spinners while the <iframe> is loading. It just looks like this:

Screen Shot 2023-12-06 at 14 14 51

Copy link
Member Author

Choose a reason for hiding this comment

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

hm not sure why the loading spinner didn't show up for you.
Generally I think we really need to show a loading spinner before the iframe is ready. It just feels like a bug sometimes, otherwise.
I've opened an issue for this in the meantime #119

.mx_Dialog_fixedWidth { width: 100% }
.mx_Dropdown_menu { max-width: 100% }

#mx_JoinRuleDropdown__public { display: none }
Copy link
Member

Choose a reason for hiding this comment

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

Let's add comments to each of these lines on what they intend to do.
This is especially helpful for later; we do not control if/how/when Element changes their markup. So we might need to make adjustments to all of these CSS rules whenever we update Element. Therefore it's important to remember everything these lines intend to do, so one can later double-check if they still do what they are supposed to do.

Copy link
Member

Choose a reason for hiding this comment

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

Also, if the intention of this specific line is to disallow creating public rooms: Why is it inside a @media ${breakpoints.phoneOnly} {? Do we only want to disallow creating public rooms on smartphones? If so, why?

Copy link
Member

@fnwbr fnwbr Dec 6, 2023

Choose a reason for hiding this comment

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

Was the intention to take away the second option from users for now?
image


/* More breathing room in the main timeline of a chat */
.mx_RoomView_timeline_rr_enabled .mx_EventTile[data-layout=group] .mx_EventTile_line,
Copy link
Member

Choose a reason for hiding this comment

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

Why did you remove these?

@fnwbr
Copy link
Member

fnwbr commented Dec 6, 2023

Alright, I've basically re-implemented the same feature within a few lines of code over in #115.
Feel free to close this PR, or modify it to still bring over the changes you did for <ServiceLink> -- which I think we want to have!

But maybe it might be easier to close this PR and start from main again, and porting the changes manually by just copy-pasting from the diff of this PR... up to you.

@fnwbr fnwbr marked this pull request as draft December 13, 2023 14:11
fnwbr added a commit that referenced this pull request Jan 17, 2024
@fnwbr
Copy link
Member

fnwbr commented Jan 17, 2024

Closing this; all handled... what I commented on in my last remark was done in 921d60f

@fnwbr fnwbr closed this Jan 17, 2024
@fnwbr fnwbr deleted the chat-create-messages branch January 17, 2024 17:05
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.

3 participants