Re: smplayer
On 26/02/2019 21:01, Ken Cunningham wrote:
> 1. The video is supposed to play in the smplayer window, but it always seems
> to want to make mplayer or mpv play it in it's own window. Not sure if this
> is a configuration thing, or if it's something to do with how we build
> mplayer / mpv -- or if the qt gui just doesn't pull in the macOS video
> correctly...
There's a configuration option IIRC that determines this. But it still
could be the build.
>
> 2. I just can't seem to find out where to put the translations so they will
> work (same with smtube, for that matter). Anyone skilled in qt who knows
> about this, please fix!
>
If properly built, Qt translations go in
/opt/local/usr/share/locale//LC_MESSAGES/_qt.qm
, usually.
find /opt/local/share -iname '*.qm'
> 3. These two ports (smtube / smplayer) are supposed to work together, but
> they weren't anticipating being born as macOS bundles -- so - have to write
> up an applescript or osa script or something I guess to launch them as
> bundles -- or maybe symlink the binaries into ${prefix}/bin/ if they can be
> happy that way.
The code should be modified to use LSOpenFromURLSpec() when launching
app bundles. There does not seem to be a Qt way to do this. You could
use `QProcess::startDetached("open ...");`
The code way is like so:
https://developer.apple.com/documentation/coreservices/1441986-lsopenfromurlspec?language=objc
LSLaunchURLSpec spec;
spec.appURL = CFURLCreateWithFileSystemPath(NULL,
CFSTR("/Applications/.../smplayer.app"), kCFURLPOSIXPathStyle, true);
spec.itemURLs = CFArrayCreate(NULL, , 1, NULL); // where values
is CFArrayRef of CFURLRefs
LSOpenFromURLSpec(spec, NULL);
CFRelease(spec.appURL);
CFRelease(spec.itemURLs);
--
Andrew
signature.asc
Description: OpenPGP digital signature
smplayer
smplayer is a popular gui for mplayer and mpv in the unix world. Looks pretty
useful, esp on older systems where VLC is no longer working. One cool feature
is the http casting to smartphones, etc, which is fun.
I ported it into MacPorts recently -- it works pretty well as an mplayer
driver, but there are a few hiccups I wouldn't mind some help with.
1. The video is supposed to play in the smplayer window, but it always seems to
want to make mplayer or mpv play it in it's own window. Not sure if this is a
configuration thing, or if it's something to do with how we build mplayer / mpv
-- or if the qt gui just doesn't pull in the macOS video correctly...
2. I just can't seem to find out where to put the translations so they will
work (same with smtube, for that matter). Anyone skilled in qt who knows about
this, please fix!
3. These two ports (smtube / smplayer) are supposed to work together, but they
weren't anticipating being born as macOS bundles -- so - have to write up an
applescript or osa script or something I guess to launch them as bundles -- or
maybe symlink the binaries into ${prefix}/bin/ if they can be happy that way.
Best,
Ken
Re: Heads up: poppler won't build
On Feb 25, 2019, at 00:41, Mojca Miklavec wrote: > This message tells you what precisely to do to work around the issue: >sudo port -f dectivate poppler >sudo port install poppler > > We usually do something like deactivate hack >https://trac.macports.org/wiki/PortfileRecipes#deactivatehack > but I don't know why it wasn't done this way (maybe it doesn't work, > maybe there were other reasons ...). As explained on the wiki page, we typically use the deactivate hack when a port now provides files that one of its dependents previously provided. Not doing so would result in activation failure, and we want to prevent users from experiencing that. That's not what's happening with poppler. Poppler has a build conflict with another port (coincidentally: with older versions of itself). In those cases, we don't use the deactivate hack; instead we notify the user of the problem by using the conflicts_build portgroup. The user can then take charge of deactivating the conflicting port before the build and reactivating it afterward. Or the user might choose to postpone the upgrade, if they happen to know that they need the conflicting port to remain active for the time being. Maybe the conflicting port is (or is required by) a server process that they want to keep running, or a utility that the user is using in a script. One could argue that we should handle both situations the same way. But the reason we handle them differently might be as follows: The deactivate hack is used when two related ports have reorganized which one of them provides which files. For example, netpbm used to provide a bunch of libraries, but I moved them to a separate libnetpbm subport, therefore I had to use the deactivate hack in libnetpbm to deactivate any already installed older copy of netpbm. One could argue that doing so makes netpbm temporarily unavailable to the user. But the most likely way for the user to encounter this situation is for them to upgrade netpbm, and if the user has consented to that, then they already expect the netpbm programs to be unavailable for a short time. In contrast, build conflicts are typically declared between unrelated ports. A user upgrading a port would most likely not expect an unrelated port to be automatically deactivated, even temporarily.
Re: Heads up: poppler won't build
On Feb 24, 2019, at 17:55, Dave Horsfall wrote: > Hmmm... Proceed regardless: > >ozzie:~ dave$ sudo port -p upgrade outdated >Nothing to upgrade. > > (Yes, I'm in the habit of using "-p" to get past broken ports.) Please do not habitually (or ideally ever) use "-p" when installing or upgrading. It will cause problems. Suppose that you have installed a port PROG that depends on a library LIB. Suppose we upgrade LIB to a new version, and that this requires PROG to be rebuilt, so we also increase the revision of PROG. You've selfupdated and received these changes, and then you run "sudo port -p upgrade PROG", which causes LIB to be upgraded first, since it is a dependency. Suppose that for whatever reason, LIB fails to build on your system. Because you used the "-p" flag, MacPorts proceeds past this failure and rebuilds PROG anyway. If MacPorts is able to get a binary of PROG from our build server, that binary will be linked with the new version of LIB, which you don't have, so PROG will be broken. If you don't get a binary, it will build on your system, linking with the old version of LIB that you already had installed, despite the fact that the only reason for the rebuild was to link with the new version of LIB. So it will look to you as if PROG built successfully, but in fact what you built was not what we intended for you to get. Worse, when whatever problem prevented LIB from building on your system is fixed and you are able to upgrade it, you will have a broken PROG because it was linked with the old LIB. We should probably modify MacPorts base to prevent using the "-p" flag for the install or upgrade actions.
Re: Heads up: poppler won't build
On Feb 24, 2019, at 19:24, Bill Cole wrote: > On 24 Feb 2019, at 18:55, Dave Horsfall wrote: > >> Sierra 10.12.6 + latest security updates, MacPorts 2.5.4. >> >> Doing my regular Monday "port upgrade outdated", and... >> >>---> Computing dependencies for poppler >>---> Configuring poppler >>Error: poppler cannot be built while another version of poppler is active. >>Error: Please forcibly deactivate the existing copy of poppler, e.g. by >> running: >>Error: >>Error: sudo port -f deactivate poppler >>Error: >>Error: Then try again. >>Error: Failed to configure poppler: poppler is active >> So, >> >>ozzie:~ dave$ sudo port -f deactivate poppler >>---> Unable to deactivate poppler @0.72.0_0, the following ports depend >> on it: >>---> gimp2 @2.10.8_3+python27 >>Warning: Deactivate forced. Proceeding despite dependencies. >>---> Deactivating poppler @0.72.0_0 >>---> Cleaning poppler >> >> Hmmm... Proceed regardless: >> >>ozzie:~ dave$ sudo port -p upgrade outdated >>Nothing to upgrade. > > Because after you deactivate a port, an "upgrade" isn't possible. That's not true, however a port is not considered outdated unless it is active. You can still upgrade it by explicitly naming it: sudo port upgrade poppler
