Implement full and custom width conversation view options

[itsmartashub]

1. Chat Width Customization [#1, #37]:

• [x] Add a settings checkbox/switch that allows users to set a full width for the chat area.
• [x] Add a settings option that allows users to set a custom width for the chat area.
• [x] Implement a slider where users can specify the desired width as a percentage of the chat width.
• [x] Ensure that the chat area dynamically adjusts to the specified width, providing a real-time preview of the changes.
• [x] Change the edit state icon position for user chats avoiding its cutting when increasing the chats width
• [x] Add reset button for all width options (chats, prompt field, sync prompt)
• [x] Cross page consistency (storage saving)

2. Prompt Field Width Customization [#37]:

• [x] Similarly, provide a settings option for customizing the width of the textarea prompt where users type their messages.
• [x] Allow users to set a custom width as a percentage, to suit their typing preferences.
• [x] Ensure that the chat area dynamically adjusts to the specified width, providing a real-time preview of the changes.
• [x] Cross page consistency (storage saving)

3. Sync Feature for Prompt Field [#38]:

• [x] Introduce a sync option for the textarea prompt width, implemented as a switch/checkbox.
• [x] When enabled, the textarea prompt width automatically follows the chat width, providing a consistent layout.
• [x] If disabled, the custom prompt width settings become active, allowing users to set their preferred width independently from the chat width.
• [x] Add a lock icon indicator on the prompt message sync custom width which will dynamically appears based on the state of the prompt sync switch value
• [x] Cross page consistency (storage saving)

4. Implement responsive full-width adjustment for chat bubbles and prompt textarea when resizing window [#39]

• [x] Only add the event listener for resizing if the user has made changes to the chat width options. If the user hasn't touched any custom options or full-width settings, the resizing event should not be triggered
• [x] Detect when the screen size is <= 768px
• [x] When the screen size meets this condition, apply a style that sets the chat bubbles and prompt textarea to full width.
• [x] Ensure that the full-width adjustment is applied smoothly during resizing, providing a seamless user experience.
• [x] ❗When the screen size is greater than 768px and the interface is being resized, remove the full-width adjustment and reset to the default or previously chosen width options. So first, I have to detect if the user change the default preferences.
• [x] Use debounce fn to prevent unnecessary resizing events and ensure smooth adjustments.

Closes: #1, #37, #38, #39

[itsmartashub]

Fix edit icon disappearance in full-width mode

In the new UI, when the full-width option is enabled, the edit icon for user chats disappears due to the restricted width of the user chat element. This pull request aims to fix this issue by repositioning the edit icon and ensuring it remains visible and accessible to users. Additionally, we will address the overflow issue by applying overflow: visible to the user chat element, while thoroughly testing for any potential layout breaks caused by this change.

• [x] Add CSS vars for repositioning the edit icon to make it easily editable via JS in full width.
• [x] Reposition the edit icon to ensure it remains visible and accessible to users.
• [x] Apply overflow: visible to the user chat element to address the overflow issue.
• [x] ❗Thoroughly test the new layout for any potential breaks, especially in elements near the user chat, as the ChatGPT dev team likely had a reason for the previous overflow-x-hidden setting.
• [x] Ensure that the fix is compatible with various screen sizes and device types.

[NeeRaj-2401]

hello @itsmartashub , i have some sugestions regarding the chat width implementation,

1. i cant see edit msg icon on my msg
2. can we have option something like slider to customize the width as per user's choice (with a min and max predefined)

[itsmartashub]

1. Hmm, it looks like the prompt field in your screenshot is synchronized with the chat width, which makes me think you're not using the latest pushed full-chat-width version. In the most recent pushed version, I restyled the edit icon to be visible and on the right bottom side of the user chat (when in full width mode). I think it's more convenient there because the Cancel and Submit edit state buttons are immediately next to it.

2. As I mentioned, I definitely plan to introduce custom width options, and I'm actually working on custom width sliders right now, and it's going great, lol 🥲

[NeeRaj-2401]

Aah ok my bad, apologies :( Its looks good, thanks 🙌

[NeeRaj-2401]

hello @itsmartashub , i did notice a small behaviour of chat-full-width implementation, it does maintain the selected width % even after smaller device breakpoint which shouldnt be the case

[itsmartashub]

hello @itsmartashub , i did notice a small behaviour of chat-full-width implementation, it does maintain the selected width % even after smaller device breakpoint which shouldnt be the case

Hi there, dear @NeeRaj-2401. Yap, I'm aware of that. Just I've got a lot on my plate these days and not a lot of free time to focus on the extension.

Also, since this extension is primarily for the desktop versions, I tend to work in a similar way. So, I always make sure everything is working properly on the desktop versions first, and then once I'm sure everything is tested, I move on to mobile (smaller breakpoints).

In this case, the full/custom width feature is far from finished, so mobile is even further away.

I hope you don't mind me asking, but I'm curious about why you think the currently selected width should be different at different breakpoints?

[NeeRaj-2401]

I hope you don't mind me asking, but I'm curious about why you think the currently selected width should be different at different breakpoints?

The only reason 😅

[itsmartashub]

I hope you don't mind me asking, but I'm curious about why you think the currently selected width should be different at different breakpoints?

The only reason 😅

I understand that. But what if someone uses the extension on tablets or phones and wants the width to be custom, say, 85% instead of 100%? If I reset the width to 100% at the tablet/phones breakpoint, this feature wouldn't make sense on smaller devices/breakpoints, right? After all, you suggested the full-width feature (and there shouldn't be such "problems" with dynamic width), if I'm not mistaken. This slider customization is just a bonus.

But I can certainly look into what I can do when the user resizes the window if that would help you. If you have a better idea than changing the widths on the window resizing event to solve this, please suggest it.