Failed to fetch kf5-kjobwidgets: No such file or directory

[Tatsh]

Attempting to install kf5-Kate.

main.log.gz

[RJVB]

Ai, forgot to commit patchfile, and I can't get at it right now. I've pushed a temporary fix - I doubt you use the +x11 variant, right? :)

[Tatsh]

I have -x11 in my global variants.conf.

[RJVB]

I have -x11 in my global variants.conf.

Interesting, you may be the only other user of the qt5-kde-x11 port in that case!

[Tatsh]

Hmm? -x11 means take away the variant. I don't want any package to use X11 (although they may use libs for utilities that are unfortunately too tied up with Xorg stuff). I feel macOS + Xorg is so buggy and barely functional compared to Linux, plus it completely lacks high DPI support on macOS.

Sent from my iPhone

On Nov 23, 2019, at 12:52, René Bertin notifications@github.com wrote:

>I have -x11 in my global variants.conf.

Interesting, you may be the only other user of the qt5-kde-x11 port in that case! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[RJVB]

On Saturday November 23 2019 11:56:20 Tatsh wrote:

Hmm? -x11 means take away the variant

Doh, of course. I didn't notice the - instead of a + :-/

I feel macOS + Xorg is so buggy and barely functional compared to Linux,

How much have you used it? I actually do most of my work under X11, and have since moving back to Mac in 2004 or so. There are some issues with remote OpenGL to and from XQuartz but otherwise it works perfectly fine. It even detects external screens being added or removed and I'm pretty certain that video playback is actually smoother and freer of artefacts on Mac than on Linux.

plus it completely lacks high DPI support on macOS.

I have no idea about that, but isn't that something that has to be handled at the application level? AFAIK the X server itself just deals with pixels but IIRC also exposes the pixel density to clients.

R

[Tatsh]

So then XQuartz' implementation should expose 144 DPI or so, especially when running Qt5 things within. I haven't seen that become functional natively or with Xquartz since Qt5 came out. That is, Kate that's in the main tree renders extremely blocky on high DPI screen (it uses Qt4).

[Tatsh]

Also have you tried remoting (over a local network you trust)? It just doesn't render correctly for me.

[Tatsh]

Anyway, I have some logs for you regarding a few packages:

• kf5-breeze main.log

• kf5-osx-integration main.log

[RJVB]

So then XQuartz' implementation should expose 144 DPI or so, especially when running Qt5 things within

Doesn't it? Note that XQuartz isn't very well maintained, the equivalent in MacPorts is better up to date (I run the Xserver from MacStrop). Qt5 uses XCB to communicate with the server; the qtdiag application can report the information. I don't have a high DPI screen so can only report what it tells me about the Linux display I'm currently working off:

Screens: 1, High DPI scaling: inactive
# 0 "eDP1" Depth: 24 Primary: yes
  Manufacturer: 
  Model: 
  Serial number: 
  Geometry: 1366x768+0+0 Available: 1366x768+0+0
  Physical size: 256x144 mm  Refresh: 60 Hz Power state: 0
  Physical DPI: 135.533,135.467 Logical DPI: 86,86 Subpixel_None
  DevicePixelRatio: 1 Pixel density: 1
  Primary orientation: 2 Orientation: 2 Native orientation: 0 OrientationUpdateMask: 0

I haven't seen that become functional natively or with Xquartz since Qt5 came out.

One does have to activate high dpi support in Qt5, I think. But don't forget that it requires jumping through some hoops to get X11 support in Qt5 for Mac, and without that you simply cannot say anything about these matters.

That is, Kate that's in the main tree renders extremely blocky on high DPI screen (it uses Qt4).

Not X11...

Also have you tried remoting (over a local network you trust)? It just doesn't render correctly for me.

Yes, often, but never fancy things. You may have seen a tweaked Mesa port in MacStrop which can be built with options that enable some form of remote OpenGL towards XQuartz, but there are things that are known not to work. Qt5 applications render just fine for the most part (including KDevelop5). But Qt isn't really designed with remote displaying in mind, rather to be run over a VNC or similar.

I do run into regular issues when I run a Qt5 app in X11 mode from the Mac, but that's due to something in libxcb (a bit of a heisenbug).

[RJVB]

• kf5-osx-integration main.log

What is the problem here? What variants are you using, and what do you get on the terminal (with or without -v but without -d)?

[Tatsh]

Seems to be a circular dep? If I try to install kf5-frameworkintegration it wants kf5-osx-integration-devel, but if I try to install that, it wants kf5-frameworkintegration.

[Tatsh]

I was able to get around the issue by commenting out the kf5-osx-integration-devel dependency in the frameworkintegration port.

Also do you know why some apps show blurry fonts? Kate does not, but Quassel and System Settings both do. Maybe it's something in my old config. Not sure.

For some reason, the menu is blocky:

Quassel channel list blurry:

Kate's labels show what it should look like:

[Tatsh]

Never mind on the above font issue. It's the NSHighResolutionCapable key and a bug in my code that was patching it in.

[RJVB]

Good eye about the circular dep; fixed. That's actually what I consider a bug in MacPorts: frameworkintegration declared a runtime dependency on the integration plugin, while the plugin had a hard dependency. That should be possible, but MacPorts insists on pulling in runtime dependencies first.

Never mind on the above issue. It's the NSHighResolutionCapable key which has to be set to <true/> and you must use touch on the .app bundle from the command line. A call to Path#touch() in Python won't work.

I was going to suggest it should be something of the sort. Curious though that using touch from within Python doesn't work. The only reasonable explanation I see for that is that the system touch command sets a different set of file times than the Python touch command, or it does something else in addition. How about the gtouch command from port:coreutils? But in a sense you're lucky that a simple touch works: there have been times when you had to "move the icon" around in order for the system to acknowledge certain changes.

[Tatsh]

That was purely my bug. I was touching the Info.plist file instead of the .app directory. Had been there for a while and somehow I didn't notice till now.

As for touch and gtouch I doubt there's any real difference.

[RJVB]

As for touch and gtouch I doubt there's any real difference.

There probably wasn't back in the day, but Apple can have introduced any kind of side-effect in their system commands since. If you expect that touching an app bundle causes LaunchServices to re-evaluate things (but only if you use the touch command) they could call into the appropriate API for achieving that.

After all, it seems a bit counterintuitive that you'd react to a changed directory timestamp rather than to a change in the actual metadata file...

[RJVB]

• kf5-breeze main.log

Could that be another circular dependency? Is that resolved too now?

[Tatsh]

• kf5-breeze main.log Could that be another circular dependency? Is that resolved too now?

Yes