New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Still need help with developing for OS X? #81

Closed
kylestev opened this Issue Dec 7, 2015 · 20 comments

Comments

Projects
None yet
6 participants
@kylestev

kylestev commented Dec 7, 2015

I'd love to help!

@kylestev kylestev changed the title from Still need help with developing on Mac? to Still need help with developing for OS X? Dec 7, 2015

@kylestev

This comment has been minimized.

Show comment
Hide comment
@kylestev

kylestev Dec 7, 2015

After downloading it and running make it would appear so... I'll poke around some more in the morning. It's getting late where I live.

kylestev commented Dec 7, 2015

After downloading it and running make it would appear so... I'll poke around some more in the morning. It's getting late where I live.

@nilsding

This comment has been minimized.

Show comment
Hide comment
@nilsding

nilsding Dec 7, 2015

Contributor

Running make fails because the file system layout on OS X is somewhat unlike to those on other Unix-like systems. Also, I think it would be better to package Syncplay as an .app on that system, rather than copying files to where they belong.

Contributor

nilsding commented Dec 7, 2015

Running make fails because the file system layout on OS X is somewhat unlike to those on other Unix-like systems. Also, I think it would be better to package Syncplay as an .app on that system, rather than copying files to where they belong.

@kylestev

This comment has been minimized.

Show comment
Hide comment
@kylestev

kylestev Dec 7, 2015

changing it to use /usr/local as the prefix seems to work as /usr is owned
by root. /usr/local is used by homebrew so it's not an uncommon pattern as
far as I know to use that directory. packaging it as an app is definitely
something to consider. the issue with that is you'll run into problems with
OS X's security settings if you aren't a verified publisher. I'm not quite
sure what the workflow is for that if you want to distribute the app
outside the App Store.
On Mon, Dec 7, 2015 at 01:29 Georg G. notifications@github.com wrote:

Running make fails because the file system layout on OS X unlike to those
on other Unix-like systems. Also, I think it would be better to package
Syncplay as an .app on that system, rather than copying files to where they
belong.


Reply to this email directly or view it on GitHub
#81 (comment).

kylestev commented Dec 7, 2015

changing it to use /usr/local as the prefix seems to work as /usr is owned
by root. /usr/local is used by homebrew so it's not an uncommon pattern as
far as I know to use that directory. packaging it as an app is definitely
something to consider. the issue with that is you'll run into problems with
OS X's security settings if you aren't a verified publisher. I'm not quite
sure what the workflow is for that if you want to distribute the app
outside the App Store.
On Mon, Dec 7, 2015 at 01:29 Georg G. notifications@github.com wrote:

Running make fails because the file system layout on OS X unlike to those
on other Unix-like systems. Also, I think it would be better to package
Syncplay as an .app on that system, rather than copying files to where they
belong.


Reply to this email directly or view it on GitHub
#81 (comment).

@nilsding

This comment has been minimized.

Show comment
Hide comment
@nilsding

nilsding Dec 7, 2015

Contributor

It seems that most people usually create a disk image (i.e. .dmg) big enough to hold the .app directory and a symlink to the /Applications directory. Regarding OS X's security settings, depending on your setting, it will display a warning on the first start and you have to open the System Preferences app to allow the system to run it.

Also, for packaging Python applications as an .app there is a tool/library/whatever similar to py2exe, namely py2app. Let's see if this thing works.

Contributor

nilsding commented Dec 7, 2015

It seems that most people usually create a disk image (i.e. .dmg) big enough to hold the .app directory and a symlink to the /Applications directory. Regarding OS X's security settings, depending on your setting, it will display a warning on the first start and you have to open the System Preferences app to allow the system to run it.

Also, for packaging Python applications as an .app there is a tool/library/whatever similar to py2exe, namely py2app. Let's see if this thing works.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 7, 2015

Contributor

Thanks for the offer! Yes, we certainly still need help getting Syncplay to work properly on OS X. The things that I am aware that we need are:

1. A way to generate a native package for Mac that "just works"
I don't know the terminology (.app files?), but if we can make some sort of installer which people can use to run Syncplay on Mac without Miniconda, command line, etc then that'd be great. Ideally it would be easily generated on a Windows or Linux machine, so we can make a new package/installer whenever a new version of Syncplay is out (and indeed it would want to be designed to support updates for future versions).

2. Double check installation instructions
If the above is not possible, review the instructions at http://syncplay.pl/guide/install/#OSX and suggest any changes if they are necessary.

3. Fix the menu bar in OS X
At present the PySide menu bar works on Windows and Linux, but not OS X. Possibly running it natively will fix that, but whatever the case we want it to show up.

4. Fix VLC/mpv on OSX
Some people have reported Syncplay making erroneous jumps/seeks, primarily in relation to VLC but also in relation to mpv. I'm not 100% sure if this is due to those programmes freezing, them mis-reporting an old position, or a combination of the above. Hopefully this will be fixed by making Syncplay run natively, but either way it wants to be fixed if possible. If it is detected that the problem is VLC/mpv's, we need enough evidence for a bug report.

5. Fix closing on VLC
It'd be nice if, when you closed via VLC, it closed Syncplay. This works fine on all OSes except OS X, where it only works half the time. This might be fixed by running Syncplay natively, but might not. I'm not sure if there is anything that can be done from our side to fix this. This is a minor issue compared to the others, and it might be fixed in the latest version of VLC.

Contributor

Et0h commented Dec 7, 2015

Thanks for the offer! Yes, we certainly still need help getting Syncplay to work properly on OS X. The things that I am aware that we need are:

1. A way to generate a native package for Mac that "just works"
I don't know the terminology (.app files?), but if we can make some sort of installer which people can use to run Syncplay on Mac without Miniconda, command line, etc then that'd be great. Ideally it would be easily generated on a Windows or Linux machine, so we can make a new package/installer whenever a new version of Syncplay is out (and indeed it would want to be designed to support updates for future versions).

2. Double check installation instructions
If the above is not possible, review the instructions at http://syncplay.pl/guide/install/#OSX and suggest any changes if they are necessary.

3. Fix the menu bar in OS X
At present the PySide menu bar works on Windows and Linux, but not OS X. Possibly running it natively will fix that, but whatever the case we want it to show up.

4. Fix VLC/mpv on OSX
Some people have reported Syncplay making erroneous jumps/seeks, primarily in relation to VLC but also in relation to mpv. I'm not 100% sure if this is due to those programmes freezing, them mis-reporting an old position, or a combination of the above. Hopefully this will be fixed by making Syncplay run natively, but either way it wants to be fixed if possible. If it is detected that the problem is VLC/mpv's, we need enough evidence for a bug report.

5. Fix closing on VLC
It'd be nice if, when you closed via VLC, it closed Syncplay. This works fine on all OSes except OS X, where it only works half the time. This might be fixed by running Syncplay natively, but might not. I'm not sure if there is anything that can be done from our side to fix this. This is a minor issue compared to the others, and it might be fixed in the latest version of VLC.

@kylestev

This comment has been minimized.

Show comment
Hide comment
@kylestev

kylestev Dec 7, 2015

  1. This looks promising for building cross platform packages: http://docs.python-guide.org/en/latest/shipping/freezing/

I'll be looking into the other issues you brought up as well.

kylestev commented Dec 7, 2015

  1. This looks promising for building cross platform packages: http://docs.python-guide.org/en/latest/shipping/freezing/

I'll be looking into the other issues you brought up as well.

@nilsding

This comment has been minimized.

Show comment
Hide comment
@nilsding

nilsding Dec 12, 2015

Contributor

I've been thinking about building a seperate frontend for Syncplay, which would be used on systems running OS X.

It could even be written in Python, since it seems that OS X comes with Cocoa/Foundation/AppKit bindings for Python preinstalled. On my system these are located at /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC.

Also, many other projects seem to do this (e.g. VLC, Handbrake to name a few)

Thoughts on that?

Contributor

nilsding commented Dec 12, 2015

I've been thinking about building a seperate frontend for Syncplay, which would be used on systems running OS X.

It could even be written in Python, since it seems that OS X comes with Cocoa/Foundation/AppKit bindings for Python preinstalled. On my system these are located at /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC.

Also, many other projects seem to do this (e.g. VLC, Handbrake to name a few)

Thoughts on that?

@es0phagus

This comment has been minimized.

Show comment
Hide comment
@es0phagus

es0phagus Dec 12, 2015

Hey, I have used the Mac version so I know all about the bugs.

I currently run Syncplay through the CrossOver app for Mac without issues (although it is not ideal).

es0phagus commented Dec 12, 2015

Hey, I have used the Mac version so I know all about the bugs.

I currently run Syncplay through the CrossOver app for Mac without issues (although it is not ideal).

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 13, 2015

Contributor

@kylestev It'd be great if someone could test some of the potential freezing solutions to see if they worked with VLC and mpv without the skipping bugs that seem to occur on some versions of OS X when running Syncplay via miniconda. Once we have a winner I need to be explained how to roll it out. Also, it'd be interesting to know if they resolve the menu bar issue and are easy to install.

@nilsding Great to hear that you have so much energy for OS X UI development. I assume having a Mac-based interface will allow for a better experience for OS X users. My main concern is that not only will it be a lot of work to do, but it will be a lot of work to maintain. At present Syncplay does not always properly separate between UI code and system logic, and more UI updates will be needed for the upcoming shared playlists feature.

@es0phagus It'd be useful if you could write a short guide on running Syncplay on Mac via CrossOver app. CrossOver is not an ideal solution as the software is not free, but if it actually works without issues then it's worth letting people know about.

Contributor

Et0h commented Dec 13, 2015

@kylestev It'd be great if someone could test some of the potential freezing solutions to see if they worked with VLC and mpv without the skipping bugs that seem to occur on some versions of OS X when running Syncplay via miniconda. Once we have a winner I need to be explained how to roll it out. Also, it'd be interesting to know if they resolve the menu bar issue and are easy to install.

@nilsding Great to hear that you have so much energy for OS X UI development. I assume having a Mac-based interface will allow for a better experience for OS X users. My main concern is that not only will it be a lot of work to do, but it will be a lot of work to maintain. At present Syncplay does not always properly separate between UI code and system logic, and more UI updates will be needed for the upcoming shared playlists feature.

@es0phagus It'd be useful if you could write a short guide on running Syncplay on Mac via CrossOver app. CrossOver is not an ideal solution as the software is not free, but if it actually works without issues then it's worth letting people know about.

@nilsding

This comment has been minimized.

Show comment
Hide comment
@nilsding

nilsding Dec 13, 2015

Contributor

@Et0h Well, I guess we should focus to seperate UI code and system logic after the implemention of the shared playlist feature is done (i.e. merged to the master branch). Once that's done, we can (hopefully) easily implement other interfaces without any problems.

Yes, it's going to be a lot of work to do, but I'm sure it will be worth it in the end. I think that maintaining the seperate UI won't be that much of a problem once it's implemented, the maintainer(s) of that part would have to communicate with the other Syncplay developers about the changes (or just read the diffs of the PySide UI) and then implement them in the Cocoa UI.

Contributor

nilsding commented Dec 13, 2015

@Et0h Well, I guess we should focus to seperate UI code and system logic after the implemention of the shared playlist feature is done (i.e. merged to the master branch). Once that's done, we can (hopefully) easily implement other interfaces without any problems.

Yes, it's going to be a lot of work to do, but I'm sure it will be worth it in the end. I think that maintaining the seperate UI won't be that much of a problem once it's implemented, the maintainer(s) of that part would have to communicate with the other Syncplay developers about the changes (or just read the diffs of the PySide UI) and then implement them in the Cocoa UI.

@blaenk

This comment has been minimized.

Show comment
Hide comment
@blaenk

blaenk Dec 13, 2015

Contributor

I have to agree with @Et0h in that it would seem to me like an unnecessary duplication of work. You do seem eager to help out with this which is great, but what if that interest passes? Who will remain to keep it maintained? The core team would want to make changes to the gui, but they may be hampered by the recognition that no one will be there to replicate the changes in the OS X code, causing divergence.

I'm under the impression that some of those applications that have native OS X gui code probably do it because they are more complex in nature---VLC certainly is---and more low-level, which might require them to access more low-level GUI functionality from the host system. I don't think syncplay requires that much complexity yet.

That said, I think your idea of at least for now focusing on decoupling the UI from the logic is definitely a worthwhile one.

I do wonder though, it was my understanding that Qt applications were supposedly basically-indistinguishable from native apps nowadays on OS X, is this not the case? Would a separate UI mainly be from a design language perspective? Would these not be changes that would possibly benefit the other platforms?

My recommendation would be to see if we can work out some of your proposed UI changes within the current Qt UI code. It would allow us to maintain a single code base without duplicating work, and I think the design changes could benefit all of the other platforms. If over the course of this we identify certain aspects that can't be done without diving deeper to Cocoa/etc., we could revisit this. Currently, however, I'm not sure what the reasons would be for keeping two separate code bases.

Contributor

blaenk commented Dec 13, 2015

I have to agree with @Et0h in that it would seem to me like an unnecessary duplication of work. You do seem eager to help out with this which is great, but what if that interest passes? Who will remain to keep it maintained? The core team would want to make changes to the gui, but they may be hampered by the recognition that no one will be there to replicate the changes in the OS X code, causing divergence.

I'm under the impression that some of those applications that have native OS X gui code probably do it because they are more complex in nature---VLC certainly is---and more low-level, which might require them to access more low-level GUI functionality from the host system. I don't think syncplay requires that much complexity yet.

That said, I think your idea of at least for now focusing on decoupling the UI from the logic is definitely a worthwhile one.

I do wonder though, it was my understanding that Qt applications were supposedly basically-indistinguishable from native apps nowadays on OS X, is this not the case? Would a separate UI mainly be from a design language perspective? Would these not be changes that would possibly benefit the other platforms?

My recommendation would be to see if we can work out some of your proposed UI changes within the current Qt UI code. It would allow us to maintain a single code base without duplicating work, and I think the design changes could benefit all of the other platforms. If over the course of this we identify certain aspects that can't be done without diving deeper to Cocoa/etc., we could revisit this. Currently, however, I'm not sure what the reasons would be for keeping two separate code bases.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 19, 2015

Contributor

As per blaenk's comments I too want to know how a native app would be different UI-wise.

nilsding's #86 appears to have resolved the menu bar issue. Onwards!

Contributor

Et0h commented Dec 19, 2015

As per blaenk's comments I too want to know how a native app would be different UI-wise.

nilsding's #86 appears to have resolved the menu bar issue. Onwards!

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 22, 2015

Contributor

Related OS X Issue: #83 ('Vlc freezes while sync play is running on Mac OS X El Captian.')

Contributor

Et0h commented Dec 22, 2015

Related OS X Issue: #83 ('Vlc freezes while sync play is running on Mac OS X El Captian.')

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 31, 2015

Contributor

Another OS X thing to fix (VLC player path issue): #91

Contributor

Et0h commented Dec 31, 2015

Another OS X thing to fix (VLC player path issue): #91

@nilsding

This comment has been minimized.

Show comment
Hide comment
@nilsding

nilsding Jan 11, 2016

Contributor

Another thing I've noticed while using Syncplay on OS X is that it seems to lose the connection to the server (and player) every minute or so for no apparent reason. Interestingly enough, it's only when the GUI is active and a file is playing. Starting Syncplay without a GUI seems to work.

Contributor

nilsding commented Jan 11, 2016

Another thing I've noticed while using Syncplay on OS X is that it seems to lose the connection to the server (and player) every minute or so for no apparent reason. Interestingly enough, it's only when the GUI is active and a file is playing. Starting Syncplay without a GUI seems to work.

@vladashram

This comment has been minimized.

Show comment
Hide comment
@vladashram

vladashram Jun 5, 2016

@Et0h Interesting, what @es0phagus suggested got me thinking. I did some testing and discovered it works well in WINE(even works with native MPV, VLC is untested), which is what programs that run Windows software on OS X and Linux use.

Also I can help you with revising the OS X installation. The Native installation instructions are a bit convoluted. I could either write better instructions, or try to write a bash script to retrieve and install the necessary stuff(or both).

I don't know too much python, I took a very small intro class a few years ago, but if you were interested I might be able to assist you with getting it running in an App package.

vladashram commented Jun 5, 2016

@Et0h Interesting, what @es0phagus suggested got me thinking. I did some testing and discovered it works well in WINE(even works with native MPV, VLC is untested), which is what programs that run Windows software on OS X and Linux use.

Also I can help you with revising the OS X installation. The Native installation instructions are a bit convoluted. I could either write better instructions, or try to write a bash script to retrieve and install the necessary stuff(or both).

I don't know too much python, I took a very small intro class a few years ago, but if you were interested I might be able to assist you with getting it running in an App package.

@es0phagus

This comment has been minimized.

Show comment
Hide comment
@es0phagus

es0phagus Jun 5, 2016

Hey, I ignored this by accident for a long time now. Err, my workaround with Crossover is behaving like the native install now -- it keeps dropping the connection to the server and reconnecting every few mins. Perhaps upgrading to the latest OS X El Capitan broke it, I do not know.

On 5 Jun 2016, at 06:26, vladashram notifications@github.com wrote:

@Et0h Interesting, what @es0phagus suggested got me thinking. I did some testing and discovered it works well in WINE(even works with native MPV, VLC is untested), which is what programs that run Windows software on OS X and Linux use.

Also I can help you with revising the OS X installation. The Native installation instructions are a bit convoluted. I could either write better instructions, or try to write a bash script to retrieve and install the necessary stuff(or both).

I don't know too much python, I took a very small intro class a few years ago, but if you were interested I might be able to assist you with getting it running in an App package.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

es0phagus commented Jun 5, 2016

Hey, I ignored this by accident for a long time now. Err, my workaround with Crossover is behaving like the native install now -- it keeps dropping the connection to the server and reconnecting every few mins. Perhaps upgrading to the latest OS X El Capitan broke it, I do not know.

On 5 Jun 2016, at 06:26, vladashram notifications@github.com wrote:

@Et0h Interesting, what @es0phagus suggested got me thinking. I did some testing and discovered it works well in WINE(even works with native MPV, VLC is untested), which is what programs that run Windows software on OS X and Linux use.

Also I can help you with revising the OS X installation. The Native installation instructions are a bit convoluted. I could either write better instructions, or try to write a bash script to retrieve and install the necessary stuff(or both).

I don't know too much python, I took a very small intro class a few years ago, but if you were interested I might be able to assist you with getting it running in an App package.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Jul 3, 2016

Contributor

I'm guessing it was the upgrading to El Captain that did it. Don't know how to resolve, but hopefully a fellow Mac user will be able to help. Is the only way to get it to work properly to use WINE?

Contributor

Et0h commented Jul 3, 2016

I'm guessing it was the upgrading to El Captain that did it. Don't know how to resolve, but hopefully a fellow Mac user will be able to help. Is the only way to get it to work properly to use WINE?

@es0phagus

This comment has been minimized.

Show comment
Hide comment
@es0phagus

es0phagus Jul 3, 2016

Yes, but now I use a virtual stimulation program called Veertu, in which I installed windows 8 and I use Syncplay via that.

On 3 Jul 2016, at 15:46, Etoh notifications@github.com wrote:

I'm guessing it was the upgrading to El Captain that did it. Don't know how to resolve, but hopefully a fellow Mac user will be able to help. Is the only way to get it to work properly to use WINE?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

es0phagus commented Jul 3, 2016

Yes, but now I use a virtual stimulation program called Veertu, in which I installed windows 8 and I use Syncplay via that.

On 3 Jul 2016, at 15:46, Etoh notifications@github.com wrote:

I'm guessing it was the upgrading to El Captain that did it. Don't know how to resolve, but hopefully a fellow Mac user will be able to help. Is the only way to get it to work properly to use WINE?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Jul 7, 2016

Contributor

It would be great if you could work on #89 and #87 and #83 and #60 or create a guide to running Syncplay on OS X via emulation (Wine, Veertu, etc)

Contributor

Et0h commented Jul 7, 2016

It would be great if you could work on #89 and #87 and #83 and #60 or create a guide to running Syncplay on OS X via emulation (Wine, Veertu, etc)

@Et0h Et0h closed this Jul 7, 2016

@Et0h Et0h added the macOS label Jul 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment