Doing More Open Source Stuff: Making Up For Lost Time

I've been a bit busy lately, and sadly haven't had much time to contribute to open source. I was looking forward to getting back on track, but ran into some hitches. In my last post, I discussed how I was set to dive into Mattermost Mobile and implement the same feature I previously worked on for the webapp - adding a setting to toggle rendering emoticons (:D) as emojis (?) - but I had to very quickly give up on that idea. Turns out WSL (Windows Subsystem for Linux) is not all that great for mobile development.

"Couldn't Be That Hard.."

Development for Mattermost is officially only supported for MacOS and Linux. This wasn't a problem when working on the webapp. While I was working on the web app, I was able to use WSL, and everything worked flawlessly. But when I tried to start working on the mobile app, I ran into problem after problem.

Following the dev environment setup instructions for Linux, I needed to set up an Android emulator, but trying to run one inside WSL didn't work - it wouldn't detect the emulator. I also couldn't just develop on Windows because the pre-install script ran a .sh script. So I spent a couple days trying to connect from inside WSL to the Android emulator running on Windows, to no avail - it just wouldn't appear in the list of emulators in WSL. I spent hours pouring over forum posts and GitHub gists, but it seemed like it just wasn’t going to work out.

I also tried forwarding my own device's USB connection to WSL to try and develop on my device. Supposedly, usbipd-win should make this work, as mentioned in this article on Microsoft Learn, and yet every time I'd retry forwarding my device to WSL, the list of connected devices would come up empty.

I searched through the message history in the official Mattermost Contributors chat, but all I found were posts from other people struggling with the same thing. So I figured the last thing I could try was to make my own post and ask for help, which thankfully, somebody did respond to to try and help, but unfortunately they were not on the mobile team and directed me to try asking in the mobile team's chat, where I've yet to receive a response.

So unfortunately, for the immediate future it seems like I won't be able to work on the issue.

Trying Something Else

In the meantime, I've been looking to pick up some other issues. While browsing for issues labelled "help wanted", I found this issue for the GitHub CLI:

`gh run view` should list branches in square brackets #10038

BagToad posted on Dec 07, 2024

Describe the bug

gh run view lists branches in parenthesis, but I think it should list them in square brackets to align with Primer guidelines:

Display branch names in brackets and/or cyan

Steps to reproduce the behavior

gh run view

Expected vs actual behavior

gh run view prompts should display branches within square brackets.

Logs

❯ gh run view
? Select a workflow run  [Use arrows to move, type to filter]
> - Verifying attestations offline fails, Discussion Triage (trunk) 4h55m1s ago
  - Decoding, Discussion Triage (patch-1) 4h59m32s ago
  ✓ Decoding, PR Automation (patch-1) 4h59m43s ago
  ✓ Issue Automation, Issue Automation (trunk) 5h20m31s ago
  - `gh repo rename myorg/newname` results in `myorg/myorg-newname`, Discussion Triage (trunk) 10h13m50s ago
  - 401 Error at every turn, Discussion Triage (trunk) 10h15m20s ago
  - 401 Error at every turn, Discussion Triage (trunk) 10h15m20s ago

View on GitHub

It seemed like a fairly straightforward change and I thought it'd be a nice break from the colossal issues I'd been undertaking - something to put me back on a decent pace again.

I was pleased with how simple the dev setup was. I already had Go installed, so all I had to do was compile the binary.

I read the contributing docs which were also very helpful and helped me get started on figuring out where to find the relevant code. I spent a little while looking through it, and found the function responsible for displaying branch names in the run command. I'd never really written Go before, but it felt very reminiscent of C's printf(). I made the change and opened a PR, but in the excitement I forgot to update the tests, which I was reminded of by a reviewer.

fix: list branches in square brackets in `gh run view` #10043

uday-rana posted on Dec 08, 2024

Fixes #10038

Changes

pkg/cmd/run/shared: Switched parentheses in selectRun() to square brackets.

Before

func selectRun() {
  ...
  fmt.Sprintf("%s %s, %s (%s) %s", ...)
  ...
}

After

func selectRun() {
  ...
  fmt.Sprintf("%s %s, %s [%s] %s", ...)
  ...
}

View on GitHub

I dug through the tests, identified the failing ones, and updated them. Unfortunately, I was then notified by a maintainer that they were in fact still in the process of triage for this issue and had preemptively applied the "help wanted" label, and that my PR may not be merged. I was a little disappointed, but I figured I'd done my part so it wasn't a big deal.

Comment for #10038

BagToad commented on Dec 09, 2024

? Hey @uday-rana, thanks for your interest picking this up!

I'd like to wait for this issue to get triaged by our first responder person on rotation this week.

I was probably too eager when adding the Help Wanted label - I still want our first responder person to triage this to ensure we agree on the work before implementing it ❤ ?

I don't foresee any issues, but I'm letting you know anyways so you know what we are waiting for before one of us reviews the PR. If our first responder person agrees, then we'll happily accept a PR ?

Apologies for the confusion! In the future, I won't add these labels early - this unintentionally skipped our triage process ?

View on GitHub

Round Two

While looking through GitHub for more issues to work on with the "help wanted" label, I found yet another Mattermost issue, this time for the webapp. Since I'd already set up the dev environment for the webapp, I figured I could quickly spring into action.

Add timestamp to pasted image filenames to differentiate them #29524

mattermod posted on Dec 09, 2024

The Problem

When pasting an image from the clipboard into the message input, it gets the filename image.png. If multiple images are pasted, they all get the same image.png filename. This can be a problem when downloading each file with the same name with danger of overwriting.

Proposed solution

Auto-generate a Filename that includes the timestamp with this format:

image-2024-11-18-6-29-57-PM

Mattermost thread: https://hub.mattermost.com/private-core/pl/xryg3tedg3bbxq3xuwnrj9ymyc

---

If you're interested please comment here and come join our "Contributors" community channel on our daily build server, where you can discuss questions with community members and the Mattermost core team. For technical advice or questions, please join our "Developers" community channel.

New contributors please see our Developer's Guide.

JIRA: https://mattermost.atlassian.net/browse/MM-62003

View on GitHub

I'm looking into this issue as of writing this blog post and I've identified the source of the problem. When posting an image from the clipboard in a browser or browser-like (a la Electron app) environment, if the image doesn't have a name, the browser will automatically give it the name "image.png". I've tested this with Firefox and Edge and it holds true for both. Why is this a problem? The app already has logic that adds timestamps to unnamed files. But since these images are automatically given names when pasting from the clipboard, the timestamps don't get set.

The easiest solution would be to just hardcode a check for the name 'image.png'. But I'm wondering what happens if the image isn't a PNG? Is that even possible in the clipboard? And what if the user is uploading a file actually named "image.png"? This is something I'll have to discuss with the developers.

Either way, I'm determined to fix this issue. Here's hoping things go smoothly.

The above is the detailed content of Doing More Open Source Stuff: Making Up For Lost Time. For more information, please follow other related articles on the PHP Chinese website!