search

RJVB / macstrop

RJVB's repository of alternative macports, with ports missing from or overriding those in the standard collection, including a set of KF5 ports.
20 stars 9 forks source link

Fix and upgrade of port:kf5-okular(-devel) #13

Closed s1bit closed 6 years ago

s1bit commented 6 years ago

Both port:kf5-okular and port:kf5-okular-devel (now at 17.12.1) work now. In-app icons are missing though.

RJVB commented 6 years ago

Icons aren't missing for me. You not seeing them means something else is fishy or misconfigured. Did you install port:kf5-osx-integration-devel?

s1bit commented 6 years ago

Yep, v5.11.2.39 installed and active.

s1bit commented 6 years ago

Update: if I run okular from the terminal, icons are there, but they do not appear if I use the bundle.

s1bit commented 6 years ago

Ok, copying script okular5 from ${prefix}/bin into the bundle and changing CFBundleExecutable into okular5 in Info.plist seems to restore icons.

RJVB commented 6 years ago

Update: if I run okular from the terminal, icons are there, but they do not appear if I use the bundle.

I don't see why it would do that. Do you have any env. variables set in your shell that are not set when you start the application via the Finder?

Did you copy the sample_native.kdeglobals file to ~/.config/kdeglobals (I made that more explicit in the notes).

It's also possible that the Finder doesn't start the application you expect; sometimes it will start the copy in the build directory, or another copy you still have somewhere.

If you want control over the settings you should install port:kf5-plasma-desktop and port:kf5-systemsettings .

The first file is opened with double click just fine, but another file would not be opened after this.

Yes, I notice that too now. To solve that I'll need to look info how I handle the OpenFile events (but I won't have time for that for a bit I'm afraid).

s1bit commented 6 years ago

I don't see why it would do that. Do you have any env. variables set in your shell that are not set when you start the application via the Finder?

Apparently, the problem is with KDE_SESSION_VERSION=5, which I do not set it up globally.

RJVB commented 6 years ago

Apparently, the problem is with KDE_SESSION_VERSION=5, which I do not set it up globally.

Ah. You could try installing kf5-osx-integration-devel with the +replace_cocoa variant set.

If you don't, you need to instruct Qt to load the platform integration plugin. With +replace_cocoa, the plugin is loaded automatically, which means that all its features become available without need for any extra settings.

I also pushed a fix for the file-opening issue you observed in the Finder; it was much easier to fix than I could hope. I've even managed to make Okular behave a bit like Preview.app; if you try to open multiple documents at once they will open in tabs in a single window (provided that Okular wasn't running already).

s1bit commented 6 years ago

Ah. You could try installing kf5-osx-integration-devel with the +replace_cocoa variant set.

Thanks! That helped.

I also pushed a fix for the file-opening issue you observed in the Finder; it was much easier to fix than I could hope. I've even managed to make Okular behave a bit like Preview.app; if you try to open multiple documents at once they will open in tabs in a single window (provided that Okular wasn't running already).

That's nice, thanks again! Actually, I would prefer to have each file opened in a separate window (à la Skim behavior), so, I've modified the patch accordingly.

Are you planning to merge your patches into the KDE code at some point? I believe the bug in utils.cpp have been known for a couple of years at least, but nobody seems to want to fix it.

RJVB commented 6 years ago

Actually, I would prefer to have each file opened in a separate window (à la Skim behavior),

Sorry, I tried to make it behave as much as possible as its native cousin :)

Are you planning to merge your patches into the KDE code at some point? I believe the bug in utils.cpp have been known for a couple of years at least, but nobody seems to want to fix it.

I've been asking myself that same question. Okular isn't the only project for which I have patches, and since it's not an application I use a lot (on Mac) I lack a bit of motivation to go through the process of presenting and justifying my patches. I'm not even certain how well the application would run with a regular Qt (besides the icon issue of course).

s1bit commented 6 years ago

Sorry, I tried to make it behave as much as possible as its native cousin :)

Haha, no problem! It's good that you found some time to fix it, such that I basically needed to remove a couple of lines to get it work as I wanted.

I've been asking myself that same question. Okular isn't the only project for which I have patches, and since it's not an application I use a lot (on Mac) I lack a bit of motivation to go through the process of presenting and justifying my patches. I'm not even certain how well the application would run with a regular Qt (besides the icon issue of course).

Well, those all patches are not tailored to the modified version of Qt, are they? I mean, they would be still relevant for the official Qt distribution, right? I could try to push those patches.

I don't think it is necessary to make it work perfectly with vanilla Qt. At least, it is not the main issue.

In the end, if we think about distribution of an application in a bundle, one would need to put all the libraries inside anyway, and then it doesn't matter, whether they are patched or not. On the other hand, in order to compile the application from source, one would need to install MacPorts/Homebrew anyway.