[GH-ISSUE #343] Feedback on v2.3.0

gitea-mirror commented

2026-05-05 05:54:12 -06:00

Owner

Originally created by @AdrianKoshka on GitHub (Jun 28, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/343

Originally assigned to: @AdrianKoshka on GitHub.

I want feedback on how well v2.3.0 works. It'll be helpful to look through existing issues if you encounter a bug and only open new ones when you find them. If barrier flat out doesn't work, I want to know.

Originally created by @AdrianKoshka on GitHub (Jun 28, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/343 Originally assigned to: @AdrianKoshka on GitHub. I want feedback on how well [v2.3.0](https://github.com/debauchee/barrier/releases/tag/v2.3.0) works. It'll be helpful to look through existing issues if you encounter a bug and only open new ones when you find them. If barrier flat out doesn't work, I want to know.

gitea-mirror

2026-05-05 05:54:12 -06:00

closed this issue
added the
help wanted

meta

query
labels

gitea-mirror commented

2026-05-05 05:54:18 -06:00

Author

Owner

@Hubcapp commented on GitHub (Jun 28, 2019):

Environment: Mac OS X 10.11.6 El Capitan

Behavior: Doesn't open a window when double clicked. The release for Barrier v2.1 does work on this older version of Mac OS X. Here what spits out in the console:

tyler-imac:Applications tyler$ open -n ./Barrier.app
LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Barrier.app.
tyler-imac:Applications tyler$ open -n ./Barrier.app --args -AppCommandLineArg
LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Barrier.app.
tyler-imac:Applications tyler$ uname -a
Darwin tyler-imac 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64
tyler-imac:Applications tyler$ open -a Barrier.app
LSOpenURLsWithRole() failed for the application /Applications/Barrier.app with error -10810.
tyler-imac:Applications tyler$ open -n Barrier.old.app
tyler-imac:Applications tyler$

@Hubcapp commented on GitHub (Jun 28, 2019): Environment: Mac OS X 10.11.6 El Capitan Behavior: Doesn't open a window when double clicked. The release for Barrier v2.1 does work on this older version of Mac OS X. Here what spits out in the console: ``` tyler-imac:Applications tyler$ open -n ./Barrier.app LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Barrier.app. tyler-imac:Applications tyler$ open -n ./Barrier.app --args -AppCommandLineArg LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Barrier.app. tyler-imac:Applications tyler$ uname -a Darwin tyler-imac 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 tyler-imac:Applications tyler$ open -a Barrier.app LSOpenURLsWithRole() failed for the application /Applications/Barrier.app with error -10810. tyler-imac:Applications tyler$ open -n Barrier.old.app tyler-imac:Applications tyler$ ```

gitea-mirror commented

2026-05-05 05:54:21 -06:00

Author

Owner

@MasterJubei commented on GitHub (Jul 1, 2019):

I just installed it, 2.3.0 on Manjaro Deepin host, client is on Windows 2.3.0.

No issues to report, only have used it for about 10 minutes. Will report issues if I find any.

@MasterJubei commented on GitHub (Jul 1, 2019): I just installed it, 2.3.0 on Manjaro Deepin host, client is on Windows 2.3.0. No issues to report, only have used it for about 10 minutes. Will report issues if I find any.

gitea-mirror commented

2026-05-05 05:54:23 -06:00

Author

Owner

@willxy commented on GitHub (Jul 1, 2019):

I'm seeing the same thing as above on osx, mine is also 10.11.6:

% open -a Barrier.app
LSOpenURLsWithRole() failed for the application /Applications/network/Barrier.app with error -10810.
% uname -a
Darwin mac 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64
% sw_vers -productVersion
10.11.6

@willxy commented on GitHub (Jul 1, 2019): I'm seeing the same thing as above on osx, mine is also 10.11.6: ``` % open -a Barrier.app LSOpenURLsWithRole() failed for the application /Applications/network/Barrier.app with error -10810. % uname -a Darwin mac 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 % sw_vers -productVersion 10.11.6 ```

gitea-mirror commented

2026-05-05 05:54:27 -06:00

Author

Owner

@sinowood commented on GitHub (Jul 8, 2019):

Environment: Two PC, both Windows 10 1903
Problem: I have been updated from v2.10 to v2.3.0, drag and drop still not working
[2019-07-08T09:58:21] INFO: drag and drop enabled
[2019-07-08T09:58:21] ERROR: failed to get desktop path, no drop target available, error=2

@sinowood commented on GitHub (Jul 8, 2019): Environment: Two PC, both Windows 10 1903 Problem: I have been updated from v2.10 to v2.3.0, drag and drop still not working [2019-07-08T09:58:21] INFO: drag and drop enabled [2019-07-08T09:58:21] ERROR: failed to get desktop path, no drop target available, error=2

gitea-mirror commented

2026-05-05 05:54:30 -06:00

Author

Owner

@woolyninja commented on GitHub (Jul 10, 2019):

MacOSX Catalina
In the Security & Privacy > Accessibility list its asking to add "sh" as an allowed Application instead of Barrier. That seems dangerous :)

@woolyninja commented on GitHub (Jul 10, 2019): MacOSX Catalina In the Security & Privacy > Accessibility list its asking to add "sh" as an allowed Application instead of Barrier. That seems dangerous :)

gitea-mirror commented

2026-05-05 05:54:32 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 10, 2019):

o.o I wonder why that is..

@AdrianKoshka commented on GitHub (Jul 10, 2019): o.o I wonder why that is..

gitea-mirror commented

2026-05-05 05:54:35 -06:00

Author

Owner

@woolyninja commented on GitHub (Jul 10, 2019):

I'm not sure - but I'm happy to try any possible fixes out if you need.

EDIT:
Ok - I was able to get it to work by changing the Info.plist
<key>CFBundleExecutable</key><string>barrier.sh</string>

to
<key>CFBundleExecutable</key><string>barrier</string>

@woolyninja commented on GitHub (Jul 10, 2019): I'm not sure - but I'm happy to try any possible fixes out if you need. EDIT: Ok - I was able to get it to work by changing the Info.plist <key>CFBundleExecutable</key><string>barrier.sh</string> to <key>CFBundleExecutable</key><string>barrier</string>

gitea-mirror commented

2026-05-05 05:54:37 -06:00

Author

Owner

@Docteh commented on GitHub (Jul 16, 2019):

I just installed v2.0.0 so that I can more easily get around to cleaning up my macbook that has 10.10.1 on it. The v2.3.0 build said it wants 10.12 or newer I think for QT, had to run it from the command line to get that error.

I guess not really what you're looking for, but a mention of minimum macOS for each build would be nice to see on the release list. After looking around a bit I think v2.1.0 might work with my old 10.10.1 so I'll give that a go.

@Docteh commented on GitHub (Jul 16, 2019): I just installed v2.0.0 so that I can more easily get around to cleaning up my macbook that has 10.10.1 on it. The v2.3.0 build said it wants 10.12 or newer I think for QT, had to run it from the command line to get that error. I guess not really what you're looking for, but a mention of minimum macOS for each build would be nice to see on the release list. After looking around a bit I think v2.1.0 might work with my old 10.10.1 so I'll give that a go.

gitea-mirror commented

2026-05-05 05:54:39 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 16, 2019):

that has 10.10.1

Don't see why a version of macOS from before 2015 would be supported. Just my 2 cents.

@AdrianKoshka commented on GitHub (Jul 16, 2019): > that has 10.10.1 Don't see why a version of macOS from before 2015 would be supported. Just my 2 cents. ![image](https://user-images.githubusercontent.com/8690255/61337612-23795300-a804-11e9-97ab-50aaa83e2a26.png)

gitea-mirror commented

2026-05-05 05:54:40 -06:00

Author

Owner

@Hubcapp commented on GitHub (Jul 17, 2019):

Windows 7 is supported & is from 2009.Some users either can't or don't want to update their operating systems, but that doesn't mean the computer is unusable.

@Hubcapp commented on GitHub (Jul 17, 2019): Windows 7 is supported & is from 2009.Some users either can't or don't want to update their operating systems, but that doesn't mean the computer is unusable.

gitea-mirror commented

2026-05-05 05:54:42 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 17, 2019):

Windows 7 goes EoL in six months, and then it won't be supported, if it builds it builds, if it doesn't it doesn't. If you don't want to update your OS, that's on you, not me. If you don't have a macbook which supports a version of macOS barrier builds on (whether that's because QT or otherwise), that's not my problem to support you. If someone wants to put in the effort and code, then sure I'll happily take that code in. Otherwise, I don't see the point.

@AdrianKoshka commented on GitHub (Jul 17, 2019): Windows 7 goes EoL in six months, and then it won't be supported, if it builds it builds, if it doesn't it doesn't. If you don't _want_ to update your OS, that's on _you_, not me. If you don't have a macbook which supports a version of macOS barrier builds on (whether that's because QT or otherwise), that's not my problem to support you. If someone wants to put in the effort and code, then sure I'll happily take that code in. Otherwise, I don't see the point.

gitea-mirror commented

2026-05-05 05:54:44 -06:00

Author

Owner

@p12tic commented on GitHub (Jul 17, 2019):

I think the value in software like Barrier partially lies in the fact that we don't need to have cost/benefit calculation so much as businesses making money. There's very long tail of users in weird configurations. So we should certainly not close the door for contributions to support them.

I'd say a better message would be that a certain configuration is not supported right now and unless some developer steps in, it will continue to be unsupported. Let's not make the impression that the door is closed.

@p12tic commented on GitHub (Jul 17, 2019): I think the value in software like Barrier partially lies in the fact that we don't need to have cost/benefit calculation so much as businesses making money. There's very long tail of users in weird configurations. So we should certainly not close the door for contributions to support them. I'd say a better message would be that a certain configuration is not supported right now and unless some developer steps in, it will continue to be unsupported. Let's not make the impression that the door is closed.

gitea-mirror commented

2026-05-05 05:54:45 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 17, 2019):

So we should certainly not close the door for contributions to support them.

In my opinion, for EoL OSes, we should close the door (It's not like we support windows XP). The problem is apple (unlike Microsoft or Cannonical) doesn't really have a lifecycle chart for the releases of their OSes?

@AdrianKoshka commented on GitHub (Jul 17, 2019): > So we should certainly not close the door for contributions to support them. In my opinion, for EoL OSes, we should close the door (It's not like we support windows XP). The problem is apple (unlike Microsoft or Cannonical) doesn't really have a lifecycle chart for the releases of their OSes?

gitea-mirror commented

2026-05-05 05:54:48 -06:00

Author

Owner

@p12tic commented on GitHub (Jul 17, 2019):

I think it may make sense to reframe the discussion a bit: we don't "support" anything in the commercial sense of "support". We're all volunteers, spending our valuable time for a cause we think is useful and want to succeed. However there's no obligation to fix bugs even in popular configurations regardless of how many complaints we get in the bug tracker.

So if there's a volunteer, who wants Windows 7 (or, I'd say, even Windows XP) to work, has the skills and time, let's let him do the work. If the result does not compromise maintainability, let's merge the code. For example, I have strong suspicion that the only reason we don't support macOS 10.10 is that we use too new Qt. There's high possibility that Barrier can be compiled on both Qt 5.<newest> and Qt 5.<old_version> without much issues, so we could in theory release more than one binary. If someone can spend time to set everything up, I don't see a good reason to refuse.

@p12tic commented on GitHub (Jul 17, 2019): I think it may make sense to reframe the discussion a bit: we don't "support" anything in the commercial sense of "support". We're all volunteers, spending our valuable time for a cause we think is useful and want to succeed. However there's no obligation to fix bugs even in popular configurations regardless of how many complaints we get in the bug tracker. So if there's a volunteer, who wants Windows 7 (or, I'd say, even Windows XP) to work, has the skills and time, let's let him do the work. If the result does not compromise maintainability, let's merge the code. For example, I have strong suspicion that the only reason we don't support macOS 10.10 is that we use too new Qt. There's high possibility that Barrier can be compiled on both Qt `5.<newest>` and Qt `5.<old_version>` without much issues, so we could in theory release more than one binary. If someone can spend time to set everything up, I don't see a good reason to refuse.

gitea-mirror commented

2026-05-05 05:54:51 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 17, 2019):

Fair. I feel like it's probably a trivial thing to do now w/ azure pipelines...I hope.

@AdrianKoshka commented on GitHub (Jul 17, 2019): Fair. I feel like it's probably a trivial thing to do now w/ azure pipelines...I hope.

gitea-mirror commented

2026-05-05 05:54:54 -06:00

Author

Owner

@p12tic commented on GitHub (Jul 17, 2019):

Having said the above, I fully agree that maintainer time is precious and it should not be spent on solving weird issues with weird configurations. But I guess that could be optimized if we consciously prioritized. Say, if it's issue with MacOS 10.10, let's just slap [osx10.10] label, mention that this platform is low priority and forget about it. Shouldn't take more than 1 minute per issue. More popular configurations can get more time whenever we think they're worth it.

@p12tic commented on GitHub (Jul 17, 2019): Having said the above, I fully agree that maintainer time is precious and it should not be spent on solving weird issues with weird configurations. But I guess that could be optimized if we consciously prioritized. Say, if it's issue with MacOS 10.10, let's just slap `[osx10.10]` label, mention that this platform is low priority and forget about it. Shouldn't take more than 1 minute per issue. More popular configurations can get more time whenever we think they're worth it.

gitea-mirror commented

2026-05-05 05:54:57 -06:00

Author

Owner

@Docteh commented on GitHub (Jul 17, 2019):

I was thinking to add some notes about version support to the release list where needed.

v2.3.0 this build requires macOS 10.12 or newer

v2.0.0 this build requires macOS 10.9 or newer

I'd take the time to file a PR if I could submit pull requests against the notes that show up under releases :)

@Docteh commented on GitHub (Jul 17, 2019): I was thinking to add some notes about version support to the release list where needed. v2.3.0 this build requires macOS 10.12 or newer v2.0.0 this build requires macOS 10.9 or newer I'd take the time to file a PR if I could submit pull requests against the notes that show up under releases :)

gitea-mirror commented

2026-05-05 05:54:59 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 17, 2019):

Updated

@AdrianKoshka commented on GitHub (Jul 17, 2019): [Updated](https://github.com/debauchee/barrier/releases/tag/v2.3.0)

gitea-mirror commented

2026-05-05 05:55:02 -06:00

Author

Owner

@izerian commented on GitHub (Jul 24, 2019):

I'm not sure - but I'm happy to try any possible fixes out if you need.

EDIT:
Ok - I was able to get it to work by changing the Info.plist
CFBundleExecutablebarrier.sh

to
CFBundleExecutablebarrier

I tried this with no luck on Catalina beta 4. Hangs on starting / failed to connect: timed out. Ports are open on the server etc.

Here's the only error in the debug log - looks like either an api changed a signature or removed it all together.

barrierc[998:37065] NSSoftLinking - The function 'SLSIsSuppressedByScreenTime' can't be found in the (null) framework.

@izerian commented on GitHub (Jul 24, 2019): > I'm not sure - but I'm happy to try any possible fixes out if you need. > > EDIT: > Ok - I was able to get it to work by changing the Info.plist > <key>CFBundleExecutable</key><string>barrier.sh</string> > > to > <key>CFBundleExecutable</key><string>barrier</string> I tried this with no luck on Catalina beta 4. Hangs on starting / failed to connect: timed out. Ports are open on the server etc. Here's the only error in the debug log - looks like either an api changed a signature or removed it all together. **barrierc[998:37065] NSSoftLinking - The function 'SLSIsSuppressedByScreenTime' can't be found in the (null) framework.**

gitea-mirror commented

2026-05-05 05:55:05 -06:00

Author

Owner

@izerian commented on GitHub (Jul 24, 2019):

Evidently it doesn't matter about the NSSoftLinking issue.

@izerian commented on GitHub (Jul 24, 2019): Evidently it doesn't matter about the NSSoftLinking issue.

gitea-mirror commented

2026-05-05 05:55:07 -06:00

Author

Owner

@GitHubRub commented on GitHub (Jul 26, 2019):

v2.3.0 works perfectly on the following setup:
Server: Windows 7 (connected to network via ethernet cable)
Client: Windows 10
Mouse: G900 set to 1000 Hz polling rate

If the client is connected to the network by Wifi, there is a delay when first moving the mouse on the client screen. This happens after a few seconds of inactivity, and is almost certainly due to either the router or OS.

If the client is connected by ethernet cable, the experience is flawless.

In both cases the polling interval is around 1ms according to MouseTester, as expected.

@GitHubRub commented on GitHub (Jul 26, 2019): v2.3.0 works perfectly on the following setup: Server: Windows 7 (connected to network via ethernet cable) Client: Windows 10 Mouse: G900 set to 1000 Hz polling rate If the client is connected to the network by Wifi, there is a delay when first moving the mouse on the client screen. This happens after a few seconds of inactivity, and is almost certainly due to either the router or OS. If the client is connected by ethernet cable, the experience is flawless. In both cases the polling interval is around 1ms according to MouseTester, as expected.

Rows
Columns

[GH-ISSUE #343] Feedback on v2.3.0 #276