Allow for collapsing gutter based on window width

[sterlingwes]

First time contributor checklist:

• I have read the README and Contributor Guidelines
• I have signed the Contributor Licence Agreement

Contributor checklist:

• My contribution is not related to translations. Please submit translation changes via our Signal Desktop Transifex project.
• My commits are in nice logical chunks with good commit messages
• My changes are rebased on the latest development branch
• A yarn ready run passes successfully (more about tests here)
• My changes are ready to be shipped to users

Description

Hello! I recently joined Signal and found myself wishing I could collapse the contact list since there's a lot of names that were added from my phone's address book that I'll never message on Signal and they take up valuable space. I figured it might be nice to collapse the gutter based on the size of the window:

signalcollapse.mp4

I think this could be improved further with a menu bar checkmark option for "View > Show Left Pane" or something that forces the window to the min. width if it's below that, to undo the collapse for those not "in the know" who may have accidentally gotten themselves in this state. Open to other suggestions for avoiding confusion here!

Fixes #2454
Fixes #3962
Related to #2155, #1871, #4331, and #3734.

[Flaburgan]

Hello @sterlingwes and thank you very much for your contribution!
Indeed, I think that a way to show the left panel even when the width is small is needed imo. Did you see my mockups there: #2454 (comment) ? What do you think?

[sterlingwes]

Hey @Flaburgan yup, I skimmed that discussion. I opened this in the hopes they'd be open to a lighter-weight approach. I figure there's a world where folks would benefit from a "focus mode" for a single chat that doesn't require a whole new small-sized gutter to always be visible. Whether it's a show/hide option in the menu bar, or some "reveal sidebar" option in the three-dot menu... there's got to be an easier solution that reduces chrome.

[Flaburgan]

@sterlingwes yeah I get that and my mockups indeed imply way more code that your PR here, but my worry with your PR is that people with a screen smaller than 800px (for example, GNU/Linux tablet or phone) won't be able to reach the conversations list at all.

[EvanHahn-Signal]

Thanks for doing this.

The good news: we're actually planning on addressing these issues in a slightly different way in the coming months. The bad news: we probably can't use this code as is. However, we'll likely refer to this code as we implement.

I'm going to close this pull request, but stay tuned for a full solution!

[Flaburgan]

@EvanHahn-Signal would it be possible to discuss (possibly privately if you prefer to do so) with someone from OWS to know the coming plans for Signal and Signal desktop? As plain GNU/Linux phones are becoming a reality with projects like Ubuntu Touch, the PinePhone and the Librem 5, a Signal app on those phones is something asked by many users. Due to the still limited number of users, I guess OWS still won't support those platforms officially for some time, so the effort is done by volunteers (currently with projects like Axolotl or Whishperfish) which are full re-implementation of Signal. This approach has many downsides so we want to change it to share most of the code with upstream. Knowing your plans and discussing with you would be very valuable, would that be possible?

[EvanHahn-Signal]

We're definitely keeping an eye on platforms like this to make sure we're spending our time effectively, but we don't discuss future plans as an organization.

[Be-ing]

@EvanHahn-Signal Outside contributors would do much of the work for you if you gave a bit of guidance. Of course, you'd still have to review the code, but that's easier than doing everything yourself.

[Flaburgan]

We're definitely keeping an eye on platforms like this to make sure we're spending our time effectively, but we don't discuss future plans as an organization.

Hm... I'm skeptical now. As an Axolotl maintainer, we basically spent hundreds of hours the last years to re-implement completely Signal because it isn't available on Ubuntu Touch and other Linux phones. The result is a client doing only the basics, not correctly secure and always lagging behind Signal in terms of features. That's not the situation we and you want. To not waste our time, collaboration between OWS and the open source community is necessary. We don't ask you to support Ubuntu Touch and other linux phones, they only have a few thousands users so it isn't worth your money. But we are working for free for you to bring your software for more users. To at least share your plans so we can avoid wasting our time seems the minimum to me. I tried to ask you on reddit during the last AMA, I asked you here on github, I pinged Moxie on Twitter, and I have not been able to have answers. How can we discuss with OWS? If really you are closed to discussions, that means we will probably not do the changes to the desktop client the way you would want it, meaning we will have to fork and maintain it ourselves. And to fork is always the worst solution in free software. Please don't close the door.

[Be-ing]

@Flaburgan I agree that a separate client reimplementing the network protocol as Axolotl does is not maintainable and also not good for security. I think the most practical way forward may be to use the new libsignal-client library with a native GTK or Qt client. libsignal-client is written in Rust and already has C, Java, and JavaScript bindings so a variety of frontends are possible. One way to do this could be using libsignal-client with Chatty, which would have some big benefits over starting a new program. Chatty already exists, so the GUI would not need be started from scratch. Also, Chatty handles SMS (and Matrix and XMPP+OMEMO) as well, which would allow users to handle all their communications in one application similar to the Signal Android client. Plus, Chatty could automatically handle the Signal registration confirmation SMS for a seamless registration experience. It seems Purism may be interested in putting resources into this considering they just made that issue public yesterday, but it would be good to get clarification on what their intentions are as well.

[Flaburgan]

Thank you for your inputs. We know about the Rust library and that could be a way to go. ButI guess Signal Desktop is already using it though, so that means we would guess both the protocol part, the UI part (users are already used to it btw) and the logic part between them if we use Signal Destkop. Basically, what we need to do is to write a middleware layer which would replace Electron and allow Signal Desktop to run on phones, handling things like contacts import. The idea is to have 99% of the code being upstream Signal and maintain almost nothing ourselves. In the best world, this middleware we be the only thing we create and OWS accepts to upstream patches to make the UI responsive & working on ARM (or do the job themselves if they don't want external contributions). That's exactly what we need to discuss with them.

[EvanHahn-Signal]

The latest beta of Signal Desktop lets you resize the left pane. Check out these instructions if you're not already on the beta.

Please try it out and open an issue if you find any bugs!