Still need help with developing for OS X?

[kylestev]

I'd love to help!

[kylestev]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

@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]

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]

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]

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

[Et0h]

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

[nilsding]

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]

@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]

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]

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]

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]

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)