[HN Gopher] Shrugs.app - A native Slack client for macOS
___________________________________________________________________
Shrugs.app - A native Slack client for macOS
Author : jer0me
Score : 291 points
Date : 2022-06-29 22:43 UTC (1 days ago)
(HTM) web link (shrugs.app)
(TXT) w3m dump (shrugs.app)
| lzli2 wrote:
| Interesting
| toxik wrote:
| Shrugs paying customer here - I emailed the devs about several
| significant bugs that were pretty much ignored. The client
| doesn't support some important features, making it basically not
| useful as a daily driver.
|
| It also has weird unread flagging behaviors that just drive you
| nuts.
|
| Would not recommend.
| jeanlucas wrote:
| Awkward, but the -\\_(tsu)_/- on the title isn't working.
| blairbeckwith wrote:
| Very important line from the FAQ:
|
| Q: Is this still developed?
|
| Yes, it is used and developed. Just not very actively. Most
| importantly Shrugs does not yet support "XOXC" tokens, which are
| often required by company Slack installations. We are interested
| in adding this feature, but there is no timeline yet.
| toxik wrote:
| In the year or so I used it, it was never updated.
| cmiles74 wrote:
| IMHO, XOXC tokens are a critical feature. If I still need the
| regular Slack client for work chat, now I have two Slack
| clients. :-(
| LtWorf wrote:
| localslackirc supports them, but it's a gateway to an IRC
| client, not a full client by itself.
| melbourne_au wrote:
| No, I'm not paying for unfinished product!
| darkstar_16 wrote:
| As much as I hate the slack electron app, I'm not completely sure
| I have a need for a native Mac app also if its not the official
| client with full feature parity. Also, I don't want more windows
| please.
| black_13 wrote:
| that_guy_iain wrote:
| > We do not offer refunds. Please make sure that you can login
| into your Slacks and that the app works for you by using the free
| test version.
|
| From my experience when someone says they don't offer refunds
| it's generally a sign that lots of people ask for their money
| back. I've not once dealt with a company that had a no refunds
| policy that was a good company to deal with.
| richrichardsson wrote:
| I run a very small audio plugin company as a side-hustle/just
| for the love of it. Refunds through my payment platform cost
| _me_ money. I offer a very generous trial (3 weeks
| unrestricted, nag screens after that). I think because of that
| no-one actually asks for refunds (or perhaps my plugins are
| good enough that everyone who buys is satisfied). I do offer
| refunds for accidental double purchases though (usually I 'm
| the one who notices and pro-actively contacts the customer).
| that_guy_iain wrote:
| I understand that refunds cost money. I have a SaaS
| boilerplate (https://getparthenon.com) with a 30-day free
| trial and then still offer a 6-month refund policy (6-months
| if you pay for the year, the full currente month if you're
| paying monthly). Why? Because I believe in my product. I also
| don't want people to go around regretting buying it, if they
| try to make something it doesn't go well for them then they
| can have their money back. Also, not many people actually ask
| for refunds. So mostly, it's just a good policy to have that
| costs me very little.
| richrichardsson wrote:
| > Also, not many people actually ask for refunds. So
| mostly, it's just a good policy to have that costs me very
| little.
|
| Actually this is a very good point and I think I very well
| may reconsider my position, because since no-one actually
| ever asks for a refund perhaps it would "look" better if I
| didn't explicitly insist that there are "no refunds".
| gnufied wrote:
| It has a free version you can use. I am not sure if refunds for
| software purchases is the norm. Does Microsoft offers Windows
| or office purchase refunds?
| [deleted]
| that_guy_iain wrote:
| It has a free version that is limited to the #general room
| which would mean for my random communities I wouldn't be able
| to test this out on the generic happenings. Nevermind a full
| blown work slack.
|
| > I am not sure if refunds for software purchases is the
| norm. Does Microsoft offers Windows or office purchase
| refunds?
|
| It is indeed the norm in the indie hacker world which this
| developer and product is part of. I don't think I've saw a
| software product that didn't come with a X-days money back
| promise.
|
| And yes, you can get a refund for Windows. You can go here
| https://answers.microsoft.com/en-
| us/windows/forum/all/return... and see a Microsoft employee
| explain how to get one.
| helge5 wrote:
| The demo version now actually supports multiple rooms (I
| think the 4 or 5 last you clicked). The bigger issue
| usually is the lack of XOXC support (as the general API
| gateway lacks a lot of API features).
|
| BTW: You can also get a refund. This is more to make sure
| that people actually try the thing before blindly buying
| something. Shrugs _does_ have limitations, so it's
| important to first test whether it fits the needs.
| paxys wrote:
| The first thing I looked for was a comparison with the official
| Slack client in terms of performance, since that's the only
| reason why I'd consider using this. Numbers for CPU load, memory
| use, time to perform certain actions, crashes. Doesn't seem to be
| anything available on the site regarding this, which is a shame.
| greenthrow wrote:
| An even better reason would potentially be security. Exploits
| in electron are pretty common, which may be a result of its
| ubiquity making it a big target. But also it's just a
| complicated platform to secure.
| anaisbetts wrote:
| .
| noptd wrote:
| >Slack is one of the most secure Electron apps currently in
| existence at the moment, _they_ have been...
|
| And from your other comment
|
| >we in the Slack Desktop team
|
| Seems misleading to declare something like this without a
| disclaimer that you work for the company in question,
| especially when phrasing it as if you are definitively
| _not_ a part of said company.
| [deleted]
| [deleted]
| xmprt wrote:
| If I was worried about security then I think I'd probably
| move to using the web client (or a web wrapper) instead of
| switching to a third party native application.
| bobblywobbles wrote:
| That's a common refrain I hear that Electron apps aren't
| secure. It was more true in the past and less-so now. I've
| been maintaining a secure Electron template for 2 years
| that's got traction in the community, if you are interested -
| https://github.com/reZach/secure-electron-template.
| Griffinsauce wrote:
| How is installing rando native apps any more secure?
| sofixa wrote:
| > crashes
|
| I've literally never had or heard of Slack crashing, across
| Windows, Ubuntu and macOS, regardless of memory available
| (8-32GB) and use. Do people really have Slack regularly crash
| on them or is that just something that gets attached to
| Electron (for some reason).
| can16358p wrote:
| Slack regularly crashes with an empty window on my Mac. Not
| like a process crash, but the whole window going empty,
| needing to quit the process and reopen.
| dijit wrote:
| A slack crash would be the window going white and reloading.
|
| I get them occasionally.
|
| An electron crash would kill the window. I get these
| sometimes too when I try to run natively in wayland, which
| I'm aware is unsupported so I'm not blaming anyone for that.
| bitexploder wrote:
| Happens to folks on my team on occasion. Slack crashing.
| And the whole Electron app crashing too. Linux users.
| skizo wrote:
| Slack crashes on my Ubuntu setup on the regular.
|
| Grey screens. Unresponsive during video calls. Eats all of my
| memory at least once a day. The app is a mess.
| e-clinton wrote:
| Not a single crash on Mac in 5 months I've been using it.
| Perhaps it's the Linux version? Or your system?
| jsjohnst wrote:
| You've never seen Slack reload while using it? Often,
| that's a "crash" in an Electron app.
| Tempest1981 wrote:
| I have not seen that. It's crash-free for me, running
| 24x7.
|
| But all that tells you is that it's crash-free on _at
| least_ a small % of machines, so not a great way to
| analyze robustness. Maybe create an HN poll?
| jsjohnst wrote:
| > I have not seen that.
|
| No offense, but you must have blinders on then. On a
| fresh install on a new machine it'll do it in the first
| day.
|
| > It's crash-free for me, running 24x7.
|
| There was a person who legit got struck by lightning
| multiple times in their life and lived, so anything is
| possible. Your claim is comparatively improbable though,
| but still has the possibility of being true.
| jclardy wrote:
| I get them all the time on my M1 Mac (Like at least once
| a week.) Sometimes even the white window that requires a
| force quit and doesn't auto-reload.
| FridgeSeal wrote:
| Slack crashes quite often for me-try to do too much?
| That's a crash.
|
| Accidentally toggled the "huddle" button a couple of
| times - it'll crash so badly, I legitimately have to
| restart the computer to fix it.
| YetAnotherNick wrote:
| I have experienced few crash like scenario with network
| issues on my Mac. If my wifi is poor for a minute, slack
| will permanently stop working unless I force reload using
| menu or restart it. Messaging apps are basically meant to
| not have permanent connection, but I have seen very few
| that could work with this assumption.
| noptd wrote:
| Slack crashes (unresponsive white window -> hard reload) for
| me at least once a day on the latest MacOS and Intel MBP, and
| it seems a common occurrence for many of the coworkers I talk
| to.
| Tagbert wrote:
| I've never seen one on Mac OS Slack
| danieldrehmer wrote:
| Most of the point of skipping electron is memory usage, which
| is a major issue with having a full separate installation of
| Chrome just to handle a webpage, which is what Slack is.
| g_delgado14 wrote:
| Want to double-down on this. I read "native" and immediately
| assumed the main selling point was perf - which enticed me to
| open the link.
| babypuncher wrote:
| Well the other selling point would be a native UI experience.
| I like apps that use the native UI style of the host
| operating system.
| Bendy wrote:
| Paying for native macOS apps is like buying vinyl records.
| It's an aesthetic choice, nothing more.
| Uupis wrote:
| It is a user experience choice. Most decent native macOS
| apps adhere to system conventions. Text editing works as
| one would expect in a system text field. Keyboard shortcuts
| behave as expected. Custom keyboard shortcut definitions
| from the Keyboard section in Preferences actually work. And
| on and on.
|
| Slack in particular is extremely, _extremely_ slow, even by
| Electron standards. I can 't expand it to the full-height
| of a 4K (running at 1080p) portrait monitor without typing
| becoming unbearably laggy, so I either have to keep it at
| 1/3 monitor height, or have to use another application for
| writing the text.
| masukomi wrote:
| it also has multiple accessibility issues for low vision
| users. I'd happily switch to a native client because
| using native widgets instead of HTML would likely address
| most, if not all, of my accessibility needs.
| tekknolagi wrote:
| I misread and thought this was a native version of a shrug copier
| for Slack, like https://shru.gg/
| anaisbetts wrote:
| .
| saagarjha wrote:
| > There is nothing about Electron that constrains it to a
| single window, what a weird idea.
|
| "Native" means both using the right UI toolkit and being a good
| citizen by supporting features that are table stakes for apps
| on the platform. Slack happens to do neither. Look, I
| understand that UI design is hard, but there's a lot of options
| that are better than "let's not do it at all". Shrugs has
| picked one and I think it's all the better for it.
| vasco wrote:
| The UI would be the same except the tab would be fixed a
| specific conversation. Perhaps worth an experiment. I know the
| purist UX view would want to adapt it to then make the new tabs
| seamless and so on but I would expect most users just really
| want to have tabs per conversation or chat or thread and be
| able to cycle tabs instead of cycling conversations using
| shortcuts. You are discounting how much comfort the brain gets
| from a mental model you are used to, and the most common app
| for people to use is the web browser, which works with tabs for
| conceptual separation of topics, which is a great analog to
| different conversations or threads.
| mdmglr wrote:
| iChat, AIM, Messenger, and Adium all had the concept of
| multiple windows for different chats.
| samanator wrote:
| The comment has been edited as if to be deleted. Does anyone
| have the original?
| santiagobasulto wrote:
| The commenter said they worked at Slack in the Desktop app
| team. He quoted the app page where it says that Shrugs.app
| supports multiple windows because it's a native app and said
| that nothing prevented Electron (or the official Slack app)
| to have multiple windows. It was just that they decided not
| to do it because of UX reasons.
| wildmanx wrote:
| > If you take more than a few minutes to think out how it works
| (I know, not popular for the typical HN poster)
|
| Such a condescending remark. This kind of thing is not good PR
| for your company, product or workplace. Would I want to work
| with colleagues who publicly disparage a whole community like
| that? If you communicate like that publicly, how can I expect
| your internal work atmosphere to be?
|
| I know you're probably an engineer at Slack and not in the PR
| department, but you may want to re-think your communication
| strategy. I know that my employer would have been unhappy with
| me for such a comment, and rightfully so.
|
| Judging by other comments in this thread, folks have apparently
| thought out how it could work for "more than a few minutes", so
| not just the style but even the content of your message are
| clearly off. You are getting community feedback here and
| competent people are giving suggestions -- for free. Embrace
| that.
| elpescado wrote:
| > There is nothing about Electron that constrains it to a
| single window, what a weird idea.
|
| Yet, for some reason, almost none of Electron apps that I'm
| aware of uses more than one window.
| santiagobasulto wrote:
| From a UX perspective, it could be useful to have different
| windows with different recurrent/common conversations. I always
| interact with the same people and channels, and I find myself
| constantly Cmd-K to those convos. If I could have several chat
| windows, I'd just arrange them on my second monitor and have
| the top-3 laying out there, so I just rotate my head, focus on
| the right convo, type and submit.
|
| Same as for reading, sometimes I just receive a quick message
| (like: "changes deployed"). I have to Cmd-K, losing focus of my
| current conversation just to switch to the other window and see
| that.
|
| Just an idea tho.
|
| EDIT: this is what I'd do: https://i.imgur.com/kI0Ti9u.png
| dmix wrote:
| This is a great start but two things:
|
| 1) the Github integration doesn't seem to be rendering the URLs
| properly which is a dealbreaker, my development channel is way
| less readable
|
| 2) Changing the default fonts would be a nice-to-have
| dubswithus wrote:
| I remember people on HN complaining about responsiveness. Never
| found it to be a problem personally.
| dijit wrote:
| Well, it's a problem for me, though definitely less than it
| was, so I'm personally very happy that this exists. "voting
| with our wallets" might make Slack put it on the prio board.
|
| Right now I'm using wee_slack.py which integrates weechat with
| slack; though with the obvious trade-offs.
| Waterluvian wrote:
| I have 300-500ms response when clicking a channel. It's
| infuriating. This happens on any browser including Electron.
| andrekandre wrote:
| that and the keyboard lag is quite noticeable (even in an m1
| machine)
|
| what is going on in software where you cant even compose text
| in realtime...
| walrus01 wrote:
| it's an obscenity that somebody pasting one high frame rate GIF
| into a slack channel can cause a quad-core, tenth generation
| core i7 laptop CPU to peg itself at 85% usage and begin wasting
| battery, heating up, spinning fans, etc.
|
| if somebody told me twenty years ago how powerful this CPU was,
| relative to what I was using at the time for a desktop PC, and
| that a _chat application_ could pretty much max out the CPU and
| use multi gigs of RAM, I would have laughed...
| rad_gruchalski wrote:
| > it's an obscenity that somebody pasting one high frame rate
| GIF into a slack channel can cause a quad-core, tenth
| generation core i7 laptop CPU to peg itself at 85% usage and
| begin wasting battery, heating up, spinning fans, etc.
|
| There's a setting to disable animated gifs. Which also
| disables party parrots and other animated crap emojis.
|
| There it is:
| https://slack.com/help/articles/228023907-Manage-animated-
| im....
| philsnow wrote:
| I also got tired of this especially when I wasn't even
| looking at Slack but it was not hidden, so it kept
| animating gifs and emoji etc that I can't see. Hammerspoon
| let me just disable them whenever I was on battery power:
|
| https://gist.github.com/philsnow/4086e07b28d8d3cd17f5bf81ff
| 8...
| paxys wrote:
| What does that have to do with Slack? If your computer has
| trouble playing high frame rate video it'll be the same on
| every application.
| lloeki wrote:
| It's not just high framerate stuff, it's pervasive.
|
| Folks used to post walls of dancing bananas in phpBB and my
| Pentium III could handle that without breaking a sweat.
|
| The exact same wall of dancing bananas makes any modern CPU
| jump to ridiculous two-digit usage relative to the task at
| hand.
|
| I was also chatting over IRC from a Palm Pilot which had
| something on the order of 1MB of RAM, connected over RS232
| to a GPRS phone, and the current experience of chat
| performance is basically on par with that, which boggles
| the mind given that I now have ten thousand times the RAM,
| an internet connection that can't be saturated in practice,
| and latency largely bound by the speed of light.
|
| Slack's requirements are _completely_ ludicrous in regard
| of what it 's set to achieve.
|
| > it'll be the same on every application.
|
| Except, it's not. Counterexamples of chat apps with
| reasonable to stellar performance abound over the last two
| decades.
| walrus01 wrote:
| Except that I can play a 4k 60fps 100Mbps bitrate HEVC
| video in vlc with 1/6th of the cpu usage slack needs to
| display a damned gif
| derekdahmer wrote:
| I wonder if it would help if Slack converted gifs to MP4s
| in the background before displaying them, or if the perf
| problem is in the compositing.
| beiller wrote:
| I think you'll notice the CPU cannot play 4K 60fps in GIF
| format. Maybe the problem is literally the format itself,
| which is terrible. It's too bad something like MPEG or
| some of the animated PNG / JPEG / WEBM formats never took
| off for meme-y animated images.
| maccard wrote:
| For a very long time (ive not checked recently) slack used more
| memory that my IDE on a multimillion line c++ project. I used
| to have to shut down slack to compile on a machine with 128GB
| ram.
| random42_ wrote:
| I think it improved quite a lot. I've just checked and it's
| using 58mb on my Windows 11 workstation.
| _jal wrote:
| > I think it improved quite a lot.
|
| Maybe on Windows. My work machine (running Big Sur)
| currently shows:
|
| Slack: 251.6MB
|
| Slack Helper: 10.2MB
|
| Slack Helper: 48.3MB (Yes, there are two of them)
|
| Slack Helper (GPU): 316.2MB
|
| Slack Helper (Renderer): 350.4MB
|
| So just shy of a gig of RAM for chat.
| KennyBlanken wrote:
| It definitely has improved. It was clear from the memory
| usage vs community size that they were doing something that
| scaled with community size. This is a guess, but something
| like loading every single user and their profile icon into
| memory.
| dubswithus wrote:
| How many gigs was it using?
| maccard wrote:
| I've changed jobs since so I don't have access to the
| tickets but I remember it being close to 20GB.
| kevingadd wrote:
| At least in my case, I once caught Slack.exe on windows
| using 40GB of RAM. (My machine had 32GB, so you can imagine
| how well things were running.) The allocated space seemed
| to have mostly been zeroes since the Windows Kernel was
| able to compress a bunch of the pages to avoid running out,
| but it was putting so much strain on things that audio
| playback was dropping out.
| wakeupcall wrote:
| After trying microsoft teams, slack feels like a thing from the
| future.
|
| But try using weechat+weeslack (+ url_hint, so that you can
| download urls and see images with a single shortcut) as one
| example of how I consider a chap app should feel.
|
| I remember pidgin being in a similar ballpark, but I haven't
| used it in years.
|
| It's a shame most other modern chat clients (ripcord, and most
| matrix clients) do not come even remotely close.
| vopi wrote:
| Maybe I'm just jaded but as someone that used to be gungho about
| alternative, native clients like these. I've just given in and
| used the official clients. I'm tired of being the person who
| doesn't have specific feature or w/e.
|
| Anyone else in a similar boat?
| elpescado wrote:
| Yeah, same here!
| that_guy_iain wrote:
| I just really want the offical clients to become native. I
| understand why they're not native but it really sucks.
| mjoin wrote:
| Yeah, same boat here!
| JacobHenner wrote:
| How long until this gets banned?
| LtWorf wrote:
| I don't think slack bans clients. They even document their
| API...
|
| I maintain an IRC gateway and have never been harassed (except
| by users using whatever strange distribution and being unable
| to figure out how to run the thing... they could just get
| debian but noooo)
| Klonoar wrote:
| It's been around for quite some time now, so... ;P
| amelius wrote:
| Perhaps when it becomes popular ...
| baby wrote:
| This is one of the least attracting landing page for one of the
| most attracting tool I've seen.
| vzaliva wrote:
| It looks nice, but if you plan to try it as you default Slack
| client be aware it is lacking many features:
|
| - Edit posted messages (big one, TBA) - Authentication w/ XOXC
| tokens - Loading older messages - Typing indicators - Starring &
| Pinning things - Search - Sharing messages - Screensharing and
| Calls (aka Screenhero) - Joining and creating channels
| wpietri wrote:
| I would also expect the authors are going to have a hard time
| keeping up with Slack. One of Slack's goals in picking their
| architecture was to allow for experimentation, iteration, and
| expansion. Reverse-engineering an API inevitably means being
| behind. And given the number of engineers Slack has, it could
| well mean being further and further behind over time.
| ungamedplayer wrote:
| When you're building on someones platform, you take a risk.
| When you're actively integrating with a fast moving platform,
| you add more risk. When you build on a platform which doesn't
| want you there, you add even more.
|
| When you're having to reverse engineer a platform to build
| something, you're asking for a special kind of hell.
| st3fan wrote:
| Yeah, but multiple windows! OMG!
|
| I find managing multiple conversations with Slack so incredibly
| challenging. Having multiple windows open for active
| conversations is sooo good.
| heretogetout wrote:
| I'd love to have multiple windows. At some point in the last
| few months Slack broke the command-up/command-down shortcuts
| that would take you to the next conversation with an unread
| message -- if you restart it'll work for a short while and
| then break again. Having multiple windows would resolve this
| and other annoyances.
| wryun wrote:
| If you use a browser as your client, this can be done. No
| need for electron either :)
| philsnow wrote:
| On Macos Chrome you can still do hamburger menu -> More
| Tools -> Create Shortcut... and enable "open as window",
| and Chrome will create a .app file that, when you run it,
| opens that site as a PWA. Additionally it gets the favicon
| of the site by default as its app icon (you can change
| that) and then it shows up in the cmd-tab list as an app
| completely separate from Chrome. This works really nicely
| with Slack, especially if you're usually only in a few
| slack teams. Inside the PWA Chrome apps you can do cmd-N to
| create a new window if you want to see multiple channels /
| threads side-by-side from the same slack team. It's a great
| user experience and pretty much the only reason I keep
| Chrome around.
|
| Firefox devs removed its PWA / "site-specific browser"
| support in
| https://bugzilla.mozilla.org/show_bug.cgi?id=1682593 .
| avggeek wrote:
| There's a GitHub project that enables you to run PWA's
| with Firefox as distinct apps (with thier own icons etc):
| https://github.com/filips123/PWAsForFirefox.
|
| Disclaimer: Haven't tried it out myself.
| philsnow wrote:
| Thanks, that's interesting but I'm not so anti-Chrome
| that I'm going to use a "custom modified Firefox runtime"
| just for PWAs. I don't even use the above trick these
| days; I've gone back to just using Slack.app.
| pxc wrote:
| That's interesting. I find managing Teams' multiple windows
| cumbersome and confusing, but find Slack very natural and
| efficient.
|
| Do you end up sending messages in the wrong chat often? Or
| missing messages or both? What do the main frustrations of a
| single window setup look like?
| ChrisMarshallNY wrote:
| _> Do you end up sending messages in the wrong chat often?_
|
| Yup. It's probably my most frequent mistake (and can be
| embarrassing). I make the same mistake with messages.
|
| What I have done to mitigate the issue, is give each
| workspace a different color theme. At least, it helps me to
| avoid crosstalk between organizations.
|
| I'm not a "native slacker," so I'm probably not a
| particularly good candidate for a focus group.
| pxc wrote:
| > What I have done to mitigate the issue, is give each
| workspace a different color theme. At least, it helps me
| to avoid crosstalk between organizations.
|
| Ok yeah the different workspaces in one window is more of
| a pain than just different channels and chats in one
| window for me, at least the way it's done in Slack. I
| haven't felt that way on IRC, for whatever reason.
| st3fan wrote:
| I lose stuff all the time when I switch between
| conversations and channels.
| aeyes wrote:
| try the back button to jump back to where you were before
| pxc wrote:
| I just navigate Slack entirely by search and redirect all
| conversations to public channel as as much as possible,
| and I find that pretty natural. CTRL+K to navigate
| between convos and channels, CTRL+F to find things based
| on content (if I don't want to think about whether
| something was in a DM or a channel, and just go back to
| the same one).
| pjdesno wrote:
| On a Mac, Teams doesn't obey many of the user interface
| guidelines, so multi-window use is unintuitive and
| difficult.
|
| Of course nothing in Mac Teams is nearly as bad as their
| incoming call notification - calls pop up _under_ all your
| existing calendar /email/... notifications, which you have
| to furiously click away in order to answer the call.
| gtirloni wrote:
| +1 It's painful to keep multiple active discussions in
| threads (or anywhere else for that matter).
| userbinator wrote:
| It's funny to see how basically all the official mainstream
| IM clients like AIM, MSN, ICQ, etc. used to be 1-window-per-
| conversation, but then in some odd wave of "modernity" (for
| lack of a better term) that was all dispensed with, and then
| now, multiple windows is somehow heralded as a new feature
| again.
|
| To me, it's just common sense that each conversation should
| be in its own window, instead of stuffing them all into one
| window that only shows one at a time.
|
| There's another comment here about how Teams' multiple
| windows is confusing, but I think that's more to do with it
| being _Teams_ than anything else; as I mentioned above, _all_
| IM clients were originally multiple-window and people
| certainly didn 't have trouble using them.
| kaidon wrote:
| Oh, this brings back lots of fun memories comparing
| developing SDI apps and MDI apps in Windows.
| MiddleEndian wrote:
| Clients like Adium (on Mac OS) and Pidgin (elsewhere, but
| honestly nothing is as nice as Adium), had a great solution
| for this. A window with tabs, but you can just drag tabs
| out and have more than one window. Plus you could style
| messages client-side. Nice and easy, better than anything
| popular today.
| kitsunesoba wrote:
| Adium was everything an IM client should be. I wish it
| would return to relevance, but with the dominance of
| closed messaging protocols that seems unlikely at best.
| ungamedplayer wrote:
| We create the poison then drink it.
| ramraj07 wrote:
| It's more to do with having a unified experience with
| mobile - slack pretty much has the exact same UI on all
| devices (only change is whether the side bar is visible,
| which just depends on screen size). For better or worse,
| not judging here.
| IshKebab wrote:
| Slack is more like IRC and as I recall most IRC clients had
| single windows.
| ace2358 wrote:
| I remember when a lot of software had heaps of windows.
| Like graphics editing apps, logic, Final Cut etc. Been a
| huge cutting back on windows for apps.
| baby wrote:
| +1, I basically go back to the DMs page all the time to find
| recent convos, that's the only way I found.
| tokamak-teapot wrote:
| I haven't tried this but... if you use Slack in a browser can
| you open new tabs for conversations?
| Groxx wrote:
| I frequently just use slack in the browser because it has
| tabs and windows. And generally performs much better.
| elpescado wrote:
| Multiple windows <3
|
| I look at the screenshots and think "we're living in the
| ~future~ 1996"!
| iLoveOncall wrote:
| Oof, I feel like just one of those would be a deal breaker for
| most, but all those missing together makes it feel more like a
| proof of concept than anything else.
|
| A $20 proof of concept.
| azinman2 wrote:
| Gotta start somewhere.
| iLoveOncall wrote:
| The problem is that according to the FAQ it's more in
| maintenance mode than in active development.
| zild3d wrote:
| missing search is a non starter. "Searchable Log of All
| Conversation and Knowledge" rings true in my experience
| crollywood wrote:
| Oof, while I highly value multiple windows - not sure I am
| ready to give up on some of the things you listed (especially
| edit & calls)
| xanaxagoras wrote:
| I just want a slack CLI client
| LtWorf wrote:
| Just use localslackirc and whatever textual irc client you want
| perhaps.
| tra3 wrote:
| An emacs slack client maybe: https://github.com/yuya373/emacs-
| slack?
| fivre wrote:
| it exists! https://github.com/wee-slack/wee-slack
| pushcx wrote:
| It has been unable to log in for the last year:
| https://github.com/wee-slack/wee-slack/issues/844
| Klonoar wrote:
| That description's accurate, but kind of burying the fact
| that it's clearly being worked on and has recent commits
| with people testing it.
|
| (Scroll through the issue to the bottom)
| pushcx wrote:
| Also it was inaccurate in that it's only been broken 364
| days, not a year.
| woodruffw wrote:
| See also: Ripcord[1], which has both Slack and Discord support.
|
| [1]: https://cancel.fm/ripcord/
| buzzert wrote:
| I still use Ripcord at work every day, and it's fantastic.
| kody wrote:
| +1 for ripcord. So much better than using a bloated web browser
| keb_ wrote:
| Ripcord is great and I use it for Discord and Slack, but it is
| far from feature complete. Important to note that Ripcord is
| developed by one person. Some major things that are lacking:
|
| * No search (Slack/Discord)
|
| * No huddles in Slack
|
| * Thread support in Discord
|
| For these reasons, I typically navigate to Discord/Slack in the
| browser when I need access to those features. Not ideal, but
| the snappiness of Ripcord over the slow bloat of Slack/Discord
| make it worth it _to me_.
| julianlam wrote:
| Is there a better frontend for Ripcord? I tried it, and while
| it's fast, it's just so utilitarian.
| keb_ wrote:
| Nope. The look is part of the appeal; it puts function over
| form, and looks native-ish instead of like a webapp.
|
| There is a theming system included, however, it only allows
| you to change colors/fonts of UI elements.
| kevingadd wrote:
| Ripcord has had search support in Slack for a while, it's
| under the Workspace menu. Otherwise, yeah. It's unfortunate
| to have to open the browser to do some of this stuff but the
| day-to-day experience of using it is great.
| keb_ wrote:
| Thanks -- I really had no idea.
| gtirloni wrote:
| I feel like it being based on Electron is the least bad thing
| about it. Native or not, you have to reach the API for
| everything and that's slow.
| keb_ wrote:
| Agree to disagree. Selecting a channel in Slack takes like
| 300ms for me almost _every_ time. There seems to be an
| inherent UI lag with Slack and Discord. Ripcord, on the
| other hand, is instantaneous.
| klabb3 wrote:
| Wholeheartedly agree that that's not acceptable
| performance, but blaming electron, which runs on chromium
| which is famously fast (despite its other issues) seems
| misguided.
|
| To me it sounds like an artifact of architectural
| choices, eg by polling before rendering to avoid flicker,
| lack of client side caching, or possibly just bloat.
| Companies won't stop their poor software practices even
| if they switched to native.
| keb_ wrote:
| The post I responded to mentioned the Electron; I was
| talking about the client performance in the browser, but
| I've had similar experiences with the Electron clients
| for Discord and Slack.
|
| I don't doubt you can make a performant snappy chat GUI
| with Electron/web tech, but more often than not, in my
| experience, Qt apps (like Ripcord) perform much better
| and are less RAM hungry.
| bartvk wrote:
| It could be an artifact of architectural choices, but
| Microsoft Teams also has that flickering/loading when
| switching tabs or chats.
| vdfs wrote:
| Won't using a 3rd party app for Discord get your account
| banned?
| keb_ wrote:
| Not necessarily, although this gets routinely brought up in
| the Ripcord Discord server. Ripcord essentially just uses the
| browser APIs, so it's not really different from opening
| Discord in Firefox.
|
| That being said, Discord can ban people at random for
| whatever reason they choose, and this has happened before.
|
| For the record, I've been using Ripcord with the same Discord
| account for 3 years, daily.
| [deleted]
| woodruffw wrote:
| It's probably against their terms of service, so maybe. It
| probably depends on a combination of (over)zealous automation
| and whether they feel it's in their expedient interest to
| crack down on.
| keb_ wrote:
| It's actually not https://discord.com/terms
|
| Although like with all things, proceed with caution.
| KennyBlanken wrote:
| Their client exists almost entirely to collect data about
| you (chiefly what games you're playing and with whom.)
| That's one reason they are so quick to ban non-official-
| client users.
| j1elo wrote:
| From today's conversation about Thunderbird 102: yes, it
| seems running a 3rd-party client has a high chance of
| receiving a ban.
|
| https://news.ycombinator.com/item?id=31914288#31915716
| thewebcount wrote:
| I use Ripcord to access Slack daily and it's... very mediocre.
| It uses Qt, so it looks terrible (but at least it's not a web
| browser). It's more native than an electron app, but not by a
| lot. It doesn't even use native scroll bars which can be really
| irritating at times. All images are thumbnail size and if you
| click to enlarge, it dumps you to the web, which slack.com just
| ignores. It logs you in and then doesn't take you to the image
| or file you clicked on.
|
| I don't hate it (as much as I hate using Slack in a web browser
| or electron app), but I certainly don't love it. I'll be giving
| Shrugs a try, but it sounds like it's missing a lot, too, so
| I'm not hopeful.
| alexb_ wrote:
| I actually downloaded Ripcord, immediately saw that they will
| "never" support video calls or embed videos, and then
| immediately uninstalled it.
|
| Why do a lot of these alternate clients purposefully leave out
| vital features?
| wolfpaws wrote:
| > they will "never" support video calls
|
| Video calls are somewhat involved, and no third-party
| implementation exists to my knowledge. Discord uses WebRTC
| over the browser, but the desktop app uses a native module
| written in C++ that I assume handles decoding, audio
| screensharing, and other related functionalities. It's not
| impossible of course, but the cognitive barrier is much
| higher than simply observing the WebSocket and HTTP requests
| to get text chat working.
| ulkesh wrote:
| It's an interesting start, but it's missing some pretty vital
| features the official Slack client has.
|
| I get how development works and I understand needing funding to
| support development, but I'll be holding off on this until there
| is at least a much closer feature parity.
|
| I suppose I'm getting too old to beta test daily driver software.
| mwint wrote:
| It'd be cool if there was a kind of "feature escrow". You might
| pay $20 today, but $5 of that is held and paid to the developer
| once a specific feature you want is implemented.
|
| There's probably too much overhead to be useful, but it'd be an
| interesting way of prioritizing features.
| ARandomerDude wrote:
| No way I would use this for internal company stuff. Is it safe?
| Probably. But it's not worth the risk to me personally unless the
| IT/management people agree to it first. At the company I work for
| (and I suspect many others) Slack is a treasure trove.
| flakyfilibuster wrote:
| my first thought - I was surprised, that I had to scroll down
| this far to find this post...
| DrewADesign wrote:
| I get the value of using native clients but the interface design
| would be a hurdle for me. For example, the message window has no
| visual hierarchy. The spacing between each message and the space
| between the username and message content are nearly the same with
| the font size being the same-- just with a heavier weight.
| Without being able to easily visually separate each message into
| a block, it just looks like a bunch of lines of text when you
| first look at it. It's tough to see without looking for it, but
| the Slack client is fantastically visually parsable. It fits a
| whole lot of functionality in there with very little interface
| clutter.
| MarcelOlsz wrote:
| Why on earth would I want to look up flights in a slack client?
| kccqzy wrote:
| It's built into the OS. You can do it in any app that chooses
| to support it. (NSDataDetector or some such.)
|
| It's a demonstration of OS integration.
| ccakes wrote:
| I think that is just a macOS thing, you can do that with a
| flight number in Messages.app today.
| [deleted]
| Mandatum wrote:
| Ripcord survived C&D letters because it didn't charge. I feel bad
| for OP for putting all this work in, because it's really cool -
| but you're going to get sued.
| amatecha wrote:
| I'm of the opinion that using unofficial clients for any online
| service should be a legal right (unless those unofficial
| clients cause harm to the respective service, but existing
| laws/regulations around that would already cover such cases).
| That doesn't mean the service has to specifically support the
| unofficial client, but they just can't intentionally block it
| (or forbid its use).
| aeyes wrote:
| I am pretty certain that I can prove any client as harmful. I
| have been on the receiving end of apps misbehaving plenty of
| times, no matter which platform (JS, iOS, Android). And these
| were official apps with dedicated development teams.
|
| Endless loops which flood you with API calls are a common
| issue, managing state is hard. Rate-limiting does not
| completely solve this.
| wildmanx wrote:
| Doesn't your API have a problem if it can be misused that
| way? In other words, shouldn't your backend by default
| distrust the client using its API, no matter whether it's
| the official one or anything else? Even the official client
| can have bugs that bring down your backend.
|
| That's what the "zero trust" philosophy is about.
| MajorBee wrote:
| Plus you can land in a situation where a user might
| associate bad experiences with an unofficial client with
| the actual service and thus leave with a bad impression
| overall.
| ungamedplayer wrote:
| I dont imagine that most users start with the unofficial
| client.
| Joeri wrote:
| This is the same argument AT&T used to forbid third party
| telephones on their network. It didn't convince then, and
| it does not convince now. Tolerating third party clients
| should just be part of the cost of doing business and part
| of the design of robust protocols.
| amatecha wrote:
| Yeah, I was thinking as I wrote it, "official clients can
| probably fulfill that bullet point" hahaha
| masukomi wrote:
| couldn't this be addressed to some reasonable agree by
| requiring someone to register their client and providing a
| fee schedule for "misbehavior"
|
| eg. if you send more than X requests per day per user you
| need to pay us $y per 100,000 requests over the limit (or
| whatever).
|
| the only requirement would be registering and providing
| billing info, which wouldn't be used if they behaved.
| [deleted]
| Shadonototra wrote:
| hopefully people at Slack are smart and they hire the dude
|
| but since they spit buggy electron shit for decade already, i
| think you are right, they'll do everything possible to shut
| this down and keep with their inefficient and bloated electron
| way
| harikb wrote:
| Slack is no longer a small private company. They are owned by
| Salesforce
| madrox wrote:
| To be fair, I'd love to see a case like this brought to court.
| I'm not sure there's great precedent here. I think a case could
| be made that Slack was not harmed through this work.
| userbinator wrote:
| The closest precedent might be something like https://en.wiki
| pedia.org/wiki/Lexmark_International,_Inc._v..... or whatever
| laws make the aftermarket parts industry legal.
| tptacek wrote:
| I'd like to hear a lawyer (HN has several) corroborate this
| "Slack must articulate harm" claim, because there is a whole
| branch of civil law that exists to enforce contracts in the
| absence of torts; as I understand it, it's called "contract
| law".
| madrox wrote:
| This is true, and not all contracts are valid. It's why I'd
| love to see a good case brought. I feel like every time
| this happens the little guy just folds instead of doubling
| down.
|
| But agree, would love to see some lawyers weigh in.
| chii wrote:
| it sucks that you could be sued if you are using a "public" api
| like this to write a client.
|
| I would like to think that as long as you do not brand yourself
| as slack or violate any trademarks, you should be able to write
| an app like this. Things like email clients would fall into
| this category.
| gtirloni wrote:
| It's not public as in an utility. It has its own Terms of
| Service.
| josephcsible wrote:
| The point is it's not fair that Terms of Service can impose
| that restriction. Just like it wasn't fair when you were
| only allowed to use phones that you rented from your phone
| company.
| tptacek wrote:
| Why isn't it fair? They run the service. What gives other
| people the right to tell them how to run it? If you don't
| like their terms, there are about 100 alternative
| projects you can use.
|
| There are pretty clear, practical reasons you might want
| to control the client of a commercial network service.
| tumult wrote:
| Author of Ripcord. You're wrong, and creating and using
| software compatible with services is fair.
| tptacek wrote:
| I don't agree that fairness requires service providers to
| provide open APIs. Open APIs are better, ceteris paribus,
| but that's as far as it goes.
| chii wrote:
| i do agree it's fair, but it's also true that the service
| provider could argue that they are supposed to be in
| total control of the service, including the front-end.
|
| It's by societal consensus that this can be made fair,
| and to convince people that it is fair, there needs to be
| a logical, indisputable argument that it's fair.
| Otherwise, the service providers can always just hide
| behind the counter-argument of being in control and TOS
| etc.
| tumult wrote:
| In the case of Discord, for example, the terms of service
| doesn't even mention third-party clients. Also, these
| services are accessible from web browsers, which are made
| by third parties. There are more reasons, like users
| being able to run whatever they want on their own
| computers, but just the ones above are enough.
| tptacek wrote:
| If the terms of service allow it, then it doesn't matter
| what it's fair or not: you're allowed to make a client
| for it. The discussion is moot.
| gtirloni wrote:
| "You may not copy, modify, create derivative works based
| upon, distribute, sell, lease, or sublicense any of our
| software or services"
|
| This seems to make it pretty clear they don't want you to
| create 3rd-party clients for their service.
| tumult wrote:
| Ripcord isn't a derivative work, both practically and in
| the legal sense. It's implemented from scratch. Ripcord
| isn't a resell of their service or a sublicense of their
| service.
| gtirloni wrote:
| If I rephrase it like this, does it make it clear?
|
| "You may not create derivative works based upon any of
| our services"
| tumult wrote:
| In the imaginary world where that's what the terms of
| service says, that's still fine for Ripcord -- Ripcord
| isn't a derivative work.
| tadfisher wrote:
| There are reasons, but it's also not smart. Organizations
| that pay for Slack pay for the service, not the shitty
| client.
| gtirloni wrote:
| You want to reduce Slack Inc to an API provider. They
| want to be a client provider too and they own the API
| server. Do you see where this won't work?
| tadfisher wrote:
| The value of Slack Inc is their API, which is currently
| de-facto locked to their client. People would still pay
| for Slack if they could use alternative clients, because
| the client is not the value.
| gtirloni wrote:
| You can argue that their client is not as good as it
| could be, that you have greater skills to deliver a
| better product, etc. But it has value, otherwise we'd all
| be using curl to access the Slack API with no downsides.
| That's clearly not the case by far.
| tadfisher wrote:
| > But it has value, otherwise we'd all be using curl to
| access the Slack API with no downsides. That's clearly
| not the case by far.
|
| Only because it's next-to-impossible to call the API,
| because of the way they lock features to their client!
| josephcsible wrote:
| What part of your argument wasn't true of the phone
| company too?
| edmundsauto wrote:
| The phone company is the sole-source provider and you
| couldn't opt for another platform. The more relevant
| analogy is soda fountains in a restaurant - the provider
| chose Coke, but I want Pepsi. (My OSS founder wanted
| Slack, I want discord.)
| josephcsible wrote:
| If Slack isn't the sole-source provider, then neither was
| the phone company, since you could also communicate by
| sending letters.
| edmundsauto wrote:
| That's a different medium, although I understand your
| point: Slack is the sole source provider of communicating
| on the Slack network. Personally, I don't think this is a
| problem or should be fixed because of how I see the
| tradeoffs and side effects. Similarly, I _want_ Apple to
| run their own app store and not allow sideloading because
| I prefer the set of tradeoffs that come with that, versus
| the other reality.
| wpietri wrote:
| Phone companies are different in that they were
| monopolies with special legal status. Slack, on the other
| hand, is just one of many private companies offering
| roughly equivalent services.
|
| You can still argue your case, of course, but phone
| companies are a bad analogy here.
| Perseids wrote:
| I assume your argument is that Slack has the "freedom of
| contract", the right to create and offer you contracts of
| their choosing (and you are free to accept or decline
| them). That right is not absolute. Workers rights limit it,
| sanctions limit it, cartel and competition laws limit it.
| There is no reason society can't agree to limit the options
| of keeping an API locked down in such contracts, especially
| for well established companies like Slack.
|
| And I think the advantages of such a law are very clear:
| More competition on front-ends could very likely create
| much better user experience (better organization of chats,
| better message and image editor, better notifications, show
| users whether messages have actually been sent).
|
| Laws are made to serve the public [1]. Being nice to
| companies is a means to an end, not the goal itself, and
| the discussion about whether API should be legally
| accessible to third party vendors (or devices/cars/...
| should be legally repairable by third party repair shops)
| should focus on whether we get better user experience,
| service, and so on, and have the question of whether
| companies will still want to offer backend-service like
| Slack under such a law _as a facet_.
|
| [1] At least they should be and everybody complaints when
| they aren't.
| jessefied123 wrote:
| This is just wrong lol. Cancel has never received C&D orders
| for Ripcord, and it does charge $20 for the Slack features.
| Please don't spread misinformation you're not even informed
| correctly on, dude. If they were going to order a C&D order to
| Cancel, then they would've done it around the project's start
| (around 6ish years ago). Actually research this stuff before
| posting posts like these, plz.
| [deleted]
| amedvednikov wrote:
| From this user's top post on HN:
|
| > Over the years I've found writing on HackerNews, Reddit and
| other online sites has given me an outlet to get creative and
| engage with folks in a way that will shift discourse towards
| something I'm more interested in. I regularly lie and pretend
| I know about topics and areas I have zero experience in. I
| began noticing I received more upvotes and engagement
| mh- wrote:
| ..yikes.
|
| someone admitting to that behavior on HN should be banned.
| that's actively hostile to the discourse here.
| mulmen wrote:
| How do you see top posts?
| amedvednikov wrote:
| Click on the username => submissions
| mulmen wrote:
| Ah, ok, I would call that a "submission" but it's an "Ask
| HN" so I see where you came up with "post".
|
| Note that the submission page is sorted chronologically,
| not by karma. So the concept of "top" is really more like
| "first".
|
| It seems you meant to point out that @Mandatum admitted
| to lying but the way you phrased it really made it
| difficult to verify the claim and came across to me like
| you were accusing @jessefied123.
|
| There were some very strong responses [1] to your
| accusation and I'm concerned that anger may be directed
| at the wrong person. When making these kinds of
| accusations you should try to be more clear. Use names
| and provide links. Also consider if the benefit of the
| accusation is worth the risk of misunderstanding.
|
| [1]: https://news.ycombinator.com/item?id=31928612
| smileybarry wrote:
| Should clarify: the comment above me by @amedvednikov is
| referring to _this comment chain 's_ original poster --
| @Mandatum -- not the parent or link submitter, and the post
| mentioned is: https://news.ycombinator.com/item?id=30838788
| mulmen wrote:
| Big yikes. Thanks for clearing this up. I totally
| misinterpreted the accusation.
| userbinator wrote:
| Sued for what, exactly?
| selcuka wrote:
| Violating the API Terms of Service [1]?
|
| > [...] Further, you will not: [...] (C) access our APIs or
| documentation in order to replicate or compete with the
| Services;
|
| [1] https://slack.com/intl/en-au/terms-of-service/api
| that_guy_iain wrote:
| I would be confused as to how an add-on service such as a
| premium Slack client would compete with Slack. It seems it
| would be complementing it and the use of the client would
| not compete but fundamentally cooperate with Slack as a
| service.
| planede wrote:
| Can they actually sue, or can they just terminate the
| service for this one account?
| kstrauser wrote:
| Sincere question: is an alternate app competing with
| Slack's services? We pay for each user who uses Slack,
| whether it's by phone, desktop, or web. The client is 100%
| free; the right to connect to their service is what costs
| money. Slack makes exactly the same whether I use their app
| or an alternative.
|
| I'm definitely not a lawyer, but it's not clear to me that
| this would violate the ToS.
| [deleted]
| tlrobinson wrote:
| I'm not a lawyer, but I believe Slack would have to show
| they were harmed in some way to successfully sue.
|
| They can certainly attempt to block 3rd party clients,
| though. Or threaten to / actually sue, even if they're
| unlikely to be successful.
| heartbreak wrote:
| Unlikely to be successful? This app has near zero chance
| of surviving a legal challenge from Slack.
| tumult wrote:
| Author of Ripcord. You don't know what you're talking
| about and shouldn't broadcast your assumptions as fact.
| gbalduzzi wrote:
| You keep commenting one-line sentences without any
| argument supporting your sentence. You may even be right,
| but am I supposed to blindly trust you, a random
| commenter from the internet?
| tumult wrote:
| I mean, you don't have to. I appreciate the skepticism. I
| am the actual author of Ripcord. I've had an account here
| for many years. You will not find someone with better
| firsthand knowledge about Ripcord surviving or not
| surviving legal challenges.
| shabble wrote:
| I'd be interested to hear more about what sort of
| challenges you have faced, and if/how you responded to
| them, if you have the time.
|
| Regardless of the upthread "well, just switch [your
| company/government/entire friend network] to an
| open/permissive service" non-answer, I think there's
| going to be ever-more need for unofficial clients for
| some of these services, and a big part of that is going
| to be how to avoid having them shut down immediately by
| service providers...
| tumult wrote:
| I would like to say stuff about it, but can't just yet.
| that_guy_iain wrote:
| They are based in Germany. They would need to be sued in
| Germany. Germany has legal insurance where you can get
| insurance and it will cover your legal bills and
| liabilites. On top of that Germany has legal restrictions
| on how much a case can cost. Slack/Saleforce would not
| have much benefit in a legal challenge due to their size
| and legal costs. Furthermore, Slack would have to have a
| legal case. Which they most likely won't have.
| Kaze404 wrote:
| It does, though. You need to buy a $20 license to use Slack's
| features.
| kevingadd wrote:
| IMO lawsuits are less of a concern than your end users getting
| banned, especially since slack is typically used for work. If
| your existing customers are loudly angry about you in public
| it's gonna make it hard to get new ones
| heretogetout wrote:
| If I got banned, I don't know what I'd do first -- open a
| bottle of champagne or dance a little jig?
| Ndymium wrote:
| I wouldn't be so sure. IRCCloud offers Slack connectivity
| (using Slack's API, not the IRC bridge that was closed long
| ago) and it costs money. I've used it for a couple of years
| now.
| ruraljuror wrote:
| One awesome UI feature of slack is that if you paste a url onto
| selected test it will automatically create a hyperlink. GitHub
| markdown does this too. Once you use, it is frustrating when
| clients don't implement it. Looking at you, Jira.
| wink wrote:
| Also one of the worst features if you paste hostnames that are
| now webpages. Always needs ``` - horrible for ops.
___________________________________________________________________
(page generated 2022-06-30 23:03 UTC)