Package Details: rocketchat-desktop 2.15.3-1

Git Clone URL: https://aur.archlinux.org/rocketchat-desktop.git (read-only)
Package Base: rocketchat-desktop
Description: Rocket.Chat Native Cross-Platform Desktop Application via Electron.
Upstream URL: https://github.com/RocketChat/Rocket.Chat.Electron
Keywords: chat client electron rocket rocketchat
Licenses: MIT
Conflicts: rocketchat-client-bin
Submitter: sum01
Maintainer: matthias.lisin
Last Packager: matthias.lisin
Votes: 10
Popularity: 0.336158
First Submitted: 2017-10-23 16:52
Last Updated: 2019-04-30 19:59

Pinned Comments

sum01 commented on 2017-10-25 17:02

If you're wondering about the difference between this and rocketchat-client-bin, this builds from the source code.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Turtizzle commented on 2019-02-25 09:06

The notification timeout works fine in the new version... I guess it's fixed by ignoring the issue. :)

matthias.lisin commented on 2019-02-24 19:01

Hello my dudes. So there we go 2.15.0 is out. The notifications timeout patch is gone and hopefully all the related issues as well.

Now depends on electron (3) instead of electron2. This is good, but might not quiet perfect since upstream actually wants electron 4(!).

As you can see in the PKGBUILD, I downgraded to electron@^3.1.4, because I noticed at least one thing that was broken. Looks like 4 is not fully backwardscompatible.

matthias.lisin commented on 2019-02-23 20:20

@Turtizzle

I didn't know what to answer or what to do. But today I saw this merged pull request arrive:

https://github.com/RocketChat/Rocket.Chat.Electron/pull/1101

This might actually solve all the notification issues. Let's hope it does.

Turtizzle commented on 2019-02-21 16:08

@matthias.lisin That's weird, I am using xfce4-notifyd and have a default timeout of 10 seconds configured, which works fine when I test it with notify-send. My rocketchat messages do not disappear though... and it used to work when I was still testing it with the hardcoded 10 seconds patch.

Honestly, the behavior I'd prefer is having a single notification that adapts when new messages arrive, similarly to how smartphones tell you about consecutive messages... or have notifications automatically disappear when you read the respective messages in RocketChat... but that's a larger issue. As for what do do now, I suppose that's up to you. You can always make it configurable in the PKGBUILD for people who prefer it differently, if you want... that's what we build packages from source for. :P

matthias.lisin commented on 2019-02-19 09:33

@ruebsd By all means, I can't see how any of my patches might have caused this. I just cleaned everything and recompiled it again and I honestly can't reproduce what I have seen on your screenshot.

Would you be so kind to compile rocketchat from source (master) and maybe from the v2.14.7 tag? Does this solve the issue? Is it really just this AUR Package?

@Turtizzle So, messages disappear after a few seconds for me on KDE. Guess it really uses the default. If I don't read the notifications in time they minimize to tray, which I'm not really sure is good or bad. What do you think about this, and should be go back to a fixed timeout instead?

ruebsd commented on 2019-02-18 18:53

@matthias.lisin, I tried rocketchat-client-bin, that aur worked without a hitch for me. As for this aur, I tried it again and got the same result I described in the previous comment. I took a screenshot of it, so I'll send you the link on irc.

matthias.lisin commented on 2019-02-18 11:59

Hello ruebsd, I can't reproduce this. Please try installing the binary package rocketchat-client-bin and tell me if you get the same issues.

ruebsd commented on 2019-02-18 11:19

I tried it the other day, but it seems like the input textbox isn't show anywhere on the screen. The main display area also seems kind of buggy - the text gets cut off on the right and doesn't wrap when you resize the window so only way to see full messages is by going fullscreen. :(

matthias.lisin commented on 2019-02-14 14:56

Some notification daemon don't set their own timeout and rely on the application, so I guess relying on the default settings might not be the best solution for those daemons.

Turtizzle commented on 2019-02-14 14:12

Reporting back after testing for 1 day myself: I've had mixed results with this particular patch. Earlier, I tested it with a hardcoded timeout of 10 seconds, which worked fine. I assumed, removing it entirely would use the default value, but now the messages won't disappear again, just like before. :/

I'll keep you informed if I figure out more.