Mac DMGs for 0.29.0

[Kazzz-S]

Dear @klayoutmatthias,

Thank you for the new major release.
As usual, different DMG packages of KLayout 0.29.0 for Mac are available as described below (0.29.0 Dropbox Link).
Please note that in this release:

1. LW*Phb311.dmg uses Qt6.6 from Homebrew to address the compilation issue.
2. HW*Phb311.dmg embeds Qt6.4 from MacPorts to address the compilation issue and the deployment problem in Qt6.6 from Homebrew.
3. Both are entirely experimental, as the migration to Qt6 is ongoing and incomplete. In my observations, the Qt6 versions (both macOS and Linux) cannot run some Qt-based Python macros that run fine in Qt5.
   Moreover, in Linux, the 2.5D view does not start.

Note

Please keep this ticket open till the next maintenance release since 0.29.0 is a new major release.

DMG file naming convention

where
(a) Type of package: ST-:standard; LW-: lightweight; HW-: heavyweight
(b) KLayout version
(c) Target OS
(d) Package serial number
(e) Qt[5|6] type: qt[5|6]MP: MacPorts; qt[5|6]Brew: Homebrew; qt5Ana3: Anaconda3
(f) Ruby type: sys: OS-bundled; mp33: Ruby3.3 from MacPorts; hb33: Ruby3.3 from Homebrew; ana3: Ruby3.2 from Anaconda3
(f) Python type: sys: OS-bundled; mp311: Python 3.11 from MacPorts; hb311: Python 3.11 from Homebrew; ana3: Python3.11 from Anaconda3

For the primary platform, macOS Monterey (12.7.4)

Five macOS DMGs for Monterey are available.

Python is (3.11, 3.11, 3.11, 3.9)=(MacPorts, Homebrew, Anaconda3, OS-bundled)
Ruby is (3.3, 3.3, 3.2, 2.6)=(MacPorts, Homebrew, Anaconda3, OS-bundled)

Srl.No.	Target OS	DMG file name	Qt5 or Qt6	Ruby	Python	Remarks
10	Monterey (12.7)	ST-klayout-0.29.0-macOS-Monterey-1-qt5MP-RsysPsys.dmg	MacPorts	OS-bundled	OS-bundled	(10)
11	Monterey (12.7) with MacPorts dev. env.	LW-klayout-0.29.0-macOS-Monterey-1-qt5MP-Rmp33Pmp311.dmg	MacPorts	MacPorts	MacPorts	(11)
12	Monterey (12.7) with Homebrew dev. env.	LW-klayout-0.29.0-macOS-Monterey-1-qt6Brew-Rhb33Phb311.dmg	Homebrew	Homebrew	Homebrew	(12)
13	Monterey (12.7) with Anaconda3 dev. env.	LW-klayout-0.29.0-macOS-Monterey-1-qt5Ana3-Rana3Pana3.dmg	Anaconda3	Anaconda3	Anaconda3	(13)
14	Monterey (12.7)	HW-klayout-0.29.0-macOS-Monterey-1-qt6MP-RsysPhb311.dmg	MacPorts	OS-bundled	Homebrew	(14)

(10) shares OS-bundled Ruby2.6 and Python3.9 (dev. tools required); Qt5 from MacPorts is embedded.
(11) shares MacPorts development environment; for those who have the matching dev. env.
(12) shares Homebrew development environment; for those who have the matching dev. env.
(13) shares Anaconda3 development environment; for those who have the matching dev. env.
(14) shares OS-bundled Ruby2.6; Qt6 from MacPorts and Python-3.11 from Homebrew are embedded, hence, heavy.

For macOS Ventura (13.6.6)

Five macOS DMGs for Ventura are available.
They were built on an Intel-CPU-based (not M1 chip) VMware Fusion 13.5.1 on Monterey (12.7.4).

Python is (3.11, 3.11, 3.11, 3.9)=(MacPorts, Homebrew, Anaconda3, OS-bundled)
Ruby is (3.3, 3.3, 3.2, 2.6)=(MacPorts, Homebrew, Anaconda3, OS-bundled)

Srl.No.	Target OS	DMG file name	Qt5 or Qt6	Ruby	Python	Remarks
20	Ventura (13.6)	ST-klayout-0.29.0-macOS-Ventura-1-qt5MP-RsysPsys.dmg	MacPorts	OS-bundled	OS-bundled	(20)
21	Ventura (13.6) with MacPorts dev. env.	LW-klayout-0.29.0-macOS-Ventura-1-qt5MP-Rmp33Pmp311.dmg	MacPorts	MacPorts	MacPorts	(21)
22	Ventura (13.6) with Homebrew dev. env.	LW-klayout-0.29.0-macOS-Ventura-1-qt6Brew-Rhb33Phb311.dmg	Homebrew	Homebrew	Homebrew	(22)
23	Ventura (13.6) with Anaconda3 dev. env.	LW-klayout-0.29.0-macOS-Ventura-1-qt5Ana3-Rana3Pana3.dmg	Anaconda3	Anaconda3	Anaconda3	(23)
24	Ventura (13.6)	HW-klayout-0.29.0-macOS-Ventura-1-qt6MP-RsysPhb311.dmg	MacPorts	OS-bundled	Homebrew	(23)

(20) shares OS-bundled Ruby2.6 and Python3.9 (dev. tools required); Qt5 from MacPorts is embedded.
(21) experimental; shares MacPorts development environment; for those who have the matching dev. env.
(22) experimental; shares Homebrew development environment; for those who have the matching dev. env.
(23) experimental; shares Anaconda3 development environment; for those who have the matching dev. env.
(24) experimental; shares OS-bundled Ruby2.6; Qt6 from MacPorts and Python-3.11 from Homebrew are embedded, hence, heavy.

For the latest macOS Sonoma (14.4.1)

Five macOS DMGs for Sonoma are available.
They were built on an Intel-CPU-based (not M1 chip) VMware Fusion 13.5.1 on Monterey (12.7.4).

Python is (3.11, 3.11, 3.11, 3.9)=(MacPorts, Homebrew, Anaconda3, OS-bundled)
Ruby is (3.3, 3.3, 3.2, 2.6)=(MacPorts, Homebrew, Anaconda3, OS-bundled)

Srl.No.	Target OS	DMG file name	Qt5 or Qt6	Ruby	Python	Remarks
30	Sonoma (14.4)	ST-klayout-0.29.0-macOS-Sonoma-1-qt5MP-RsysPsys.dmg	MacPorts	OS-bundled	OS-bundled	(30)
31	Sonoma (14.4) with MacPorts dev. env.	LW-klayout-0.29.0-macOS-Sonoma-1-qt5MP-Rmp33Pmp311.dmg	MacPorts	MacPorts	MacPorts	(31)
32	Sonoma (14.4) with Homebrew dev. env.	LW-klayout-0.29.0-macOS-Sonoma-1-qt6Brew-Rhb33Phb311.dmg	Homebrew	Homebrew	Homebrew	(32)
33	Sonoma (14.4) with Anaconda3 dev. env.	LW-klayout-0.29.0-macOS-Sonoma-1-qt5Ana3-Rana3Pana3.dmg	Anaconda3	Anaconda3	Anaconda3	(33)
34	Sonoma (14.4)	HW-klayout-0.29.0-macOS-Sonoma-1-qt6MP-RsysPhb311.dmg	MacPorts	OS-bundled	Homebrew	(34)

(30) shares OS-bundled Ruby2.6 and Python3.9 (dev. tools required); Qt5 from MacPorts is embedded.
(31) experimental; shares MacPorts development environment; for those who have the matching dev. env.
(32) experimental; shares Homebrew development environment; for those who have the matching dev. env.
(33) experimental; shares Anaconda3 development environment; for those who have the matching dev. env.
(34) experimental; shares OS-bundled Ruby2.6; Qt6 from MacPorts and Python-3.11 from Homebrew are embedded, hence, heavy.

For previous OS

Srl.No.	Target OS	DMG file name	Qt5	Ruby	Python	Remarks
6	Big Sur (11.7.10)	From 0.28.13 onward, DMGs will not be provided for this OS.				(1p)
7	Catalina (10.15.7)	From 0.28.13 onward, DMGs will not be provided for this OS.				(1p)
8	Mojave (10.14)	From 0.27.x onward, DMGs will not be provided for this OS.				(1p)
9	HighSierra (10.13)	From 0.27.x onward, DMGs will not be provided for this OS.				(1p)
10	Sierra (10.12)	From 0.27.x onward, DMGs will not be provided for this OS.				(1p)
11	ElCapitan (10.11)	From 0.27.x onward, DMGs will not be provided for this OS.				(1p)
x	Yosemite (10.10)	has been dropped due to the compiler issue reported in #360.

(1p) From 0.28.13 onward, build is no longer possible.

With warm regards,
Kazzz-S

[klayoutmatthias]

Thanks at lot! Files are on the server and I will leave this ticket open.

I did not dare to publish the Qt6 binaries as I feel that would create a support issue. Let me know if you think it makes send to publish them too.

Regarding Qt6: I am on Ubuntu 22 and with the Qt 6.4.2. 2.5d view is working on my combination (Nvidia T1200 with version 550 driver):

However, OpenGL is highly dependent on the driver and on the Mesa library, so that is just a personal snapshot.

Apart from that: when you say some Qt-based Python macros do not run - is that because of the changed API (Qt6 vs. Qt5), or is that not related to that?

Best regards,

Matthias

[Kazzz-S]

Hello @klayoutmatthias,

I did not dare to publish the Qt6 binaries as I feel that would create a support issue. Let me know if you think it makes send to publish them too.

Thanks for your consideration.
I agree with you. It's a wise decision. Let's see the response from the community.

Apart from that: when you say some Qt-based Python macros do not run - is that because of the changed API (Qt6 vs. Qt5), or is that not related to that?

I'm not entirely certain so far. However, I feel this is most likely due to the changed API.

Example-1 (KLayout's example)

Example-2 (my own)

The above dialog (I hope the function is self-explanatory) does not show up in the Qt6 version.

In the console, I got the warning:

In the source, I have written:

Best regards,
Kazzz-S

[Kazzz-S]

cont.

Apart from that: when you say some Qt-based Python macros do not run - is that because of the changed API (Qt6 vs. Qt5), or is that not related to that?

I'm not entirely certain so far. However, I feel this is most likely due to the changed API.

It looks like both the changed API and other causes are mixed up.

(1) I have changed the code to fix the above warning.

(2) Then another warning comes up.

(3) In the Qt5 version binaries:

(4) But in the Qt6 version binaries:

(5) MacPorts and Homebrew both have the QtDesigner framework installed

---

I'll check this in my office Linux environment tomorrow.

Regards,
Kazzz-S

[klayoutmatthias]

Hello @Kazzz-S,

The QFont object got some more constructors in Qt6, so there may be some ambiguity. I can't see how exactly you call QFont, but this version is working both on Qt5 and Qt6:

pya.QFont("helvetica", 12)

(12 is the point size). I suspect that the first argument is not exactly a string. In Qt6, you can also give multiple families, maybe that creates the ambiguity:

# New in Qt6
pya.QFont(["helvetica", "times"], 12)

(1) Regarding "QIODevice": Using "QIODevice.ReadMode" definitely is universal. They have split "QIODevice" into "QIODevice" and "QIODeviceBase" and "OpenModeFlag" now is inside "QIODeviceBase" as you correctly noticed.

(2) Indentation errors usually come from Python - maybe some Python versions are more picky then others. I don't think this is related to the Qt version.

(3) The "QtDesigner" module was not really a good idea from the beginning. It is made for creating Qt Designer plugins, but I provided it mainly for the "QFormBuilder" class which can be replaced easily by "QUiLoader" from the "QtUiTools" module. The latter is available since many years now and is the better alternative in terms of functionality and support within Qt distributions.

Do you see a specific need for the "QFormBuilder" class?

Thanks and best regards,

Matthias

[Kazzz-S]

Hello @klayoutmatthias,

Thanks for these explanations.
I'll study one by one, taking time.

Do you see a specific need for the "QFormBuilder" class?

The answer is YES and NO.
When I started studying Python macros with UI, the sample program was a golden reference.

Since it worked fine, to be honest, I never considered changing the code until today.
But I do not remember where I picked QIODevice_OpenModeFlag.ReadOnly from;-(
Maybe from some Web info.

Basically, I do not need to create Qt Designer plugins.
So I can refactor the code using "QUiLoader".
This will be my work today. :-)

With best regards,
Kazzz-S

---

Using QUiLoader() in my office Linux environment...

[Kazzz-S]

cont.

The Font issues

The problem was the usage of the font-weight integer constant.
By changing the code, as shown below, the dialog appears as (almost) expected.

Thanks for the hint.
Kazzz-S

[Kazzz-S]

cont.

The 2.5d issues

About GPU

In the Qt5 environment

In the Qt6 environment (using the debug build)

I'm unsure how much it would be helpful, but I attached the Valgrind output.
2.5D-logs.zip

Best regards,
Kazzz-S

[klayoutmatthias]

Hi @Kazzz-S,

thanks for these pointers ... I need to digest that :)

1.) Thank you for pointing me to QFormBuilder use in the documentation and the samples - I will change that to QUiLoader

2.) Regarding the font issue: I see the point. The Qt declaration is kind of sloppy as it takes an int, but "Bold" is an enum in Qt6. KLayout does not automatically convert Enums to int.

The following variants work both in Qt5 and Qt6 for me:

font = pya.QFont('Times', 16, int(pya.QFont.Bold))

font = pya.QFont('Times', 16)
font.weight = pya.QFont.Bold

3.) You mention that the buttons are disabled, but not grayed out. That does not appear to be a general rule in Qt6, but maybe that is style dependent? I hardly disable buttons, mainly because I usually don't remember why they are disabled and how I can make them enabled again ... I rather like buttons showing an error and some explanation why I was not supposed to click it :)

4.) About OpenGL I guess I need to dig more into the details of that. Robust OpenGL programming apparently is some art I did not master yet. Maybe it is required to provide different versions of the shader code, depending on the capabilities of the graphics driver and the OpenGL version. I also think that not all of the computational stuff - like the normals - computation needs to be done in the shader code. Maybe that way the shader code can be simplified and reduced to a level acceptable for all graphics drivers.

Best regards,

Matthias

[lukasc-ubc]

Hello @Kazzz-S @klayoutmatthias

I notice that we are missing a HW version for this release on the KLayout web page. Kazz created a Qt6 HW but not Qt5. Would it be possible to have this HW version available? My students and I rely on Python3, and having it embedded makes easy to install and use. I'd rather not supporting people having to install their own Python3 environment and using the LW version.

I tried the ST version, and on Monterey it does show up with Python 3. But I get a lot of access messages (despite having allowed them multiple times, and approved them in System Settings > Privacy > Files and Folders.

I then installed 0.27.19 ST Monterey version, and I do not get these access problems. So it seems like something in 0.29 is causing an issue where it keeps asking for access permission.

Strangely, I was able to solve fix it, by manually saving a layout to the folders it was asking about. Then the approval seemed to stick.

So, ST vs HW -- is there a reason for me to ask for HW version, or is the ST one fine?

thank you

[Kazzz-S]

Hello @lukasc-ubc,

Thanks for your feedback.

1. HW- *.dmg with Qt5

I notice that we are missing a HW version for this release on the KLayout web page. Kazz created a Qt6 HW but not Qt5. Would it be possible to have this HW version available? My students and I rely on Python3, and having it embedded makes easy to install and use. I'd rather not supporting people having to install their own Python3 environment and using the LW version.

I used Qt6 from Homebrew for the LW-*-qt6Brew-Rhb33Phb311.dmg package mainly because of the problem reported in this ticket, where I proposed to change the build configuration for the present Qt5 binary distribution. However, Homebrew people rejected it. Instead, they suggested switching to Qt6.
For the HW-*.dmg, I could embed Qt6 from Homebrew. However, I found a problem in the deployed Qt6 (6.6.x) binaries.
More precisely, some Qt6 frameworks were not correctly deployed, which prevented the application from finding some Qt libraries at the start-up. This looks like a bug in Qt 6.6.x. Therefore, I borrowed Qt 6.4.3 from MacPorts.

If Qt6 is inconvenient for you and your students, I can build another HW-*.dmg by borrowing Qt5 from MacPorts. From the users' point of view, there should be no difference from the 0.28.17 version HW-*.dmg.
I have uploaded such a package HW-klayout-0.29.0-macOS-Monterey-1-qt5MP-RsysPhb311.dmg (built on Intel Mac Monterey) to this Dropbox link. This package will also run on Ventura and Sonoma. Please give it a shot and get back to me.

[Edit]
I have also built on Ventura and Sonoma.
Note that the contents of Homebrew-HUser-ReadMeFirst.txt have not yet reflected the changes from Qt6 to Qt5.

---

2. File Access Permission Issue

I tried the ST version, and on Monterey it does show up with Python 3. But I get a lot of access messages (despite having allowed them multiple times, and approved them in System Settings > Privacy > Files and Folders.
I then installed 0.27.19 ST Monterey version, and I do not get these access problems. So it seems like something in 0.29 is causing an issue where it keeps asking for access permission.
Strangely, I was able to solve fix it, by manually saving a layout to the folders it was asking about. Then the approval seemed to stick.

In my experience, this is a one-time warning for a new binary package (~0.28.17 and 0.29.0). Once granted, the approval appears to be permanent.

---

3. ST- vs HW-

is there a reason for me to ask for HW version, or is the ST one fine?

My preference is ST-. It would be easiest if you could tolerate the following:

1. Students need to install the Xcode command line tools, including Python3.
2. The method of installing various Python packages using pip will change. That is, $ sudo /usr/bin/python3 -m pip install <package(s)>

On the other, if the above new HW-*.dmg using Qt5 from MacPorts can be used, I think it would be good from the curriculum's continuity perspective. Because you won't need to change the existing teaching materials.

Another point to think about is the Python3 version. As of today,

1. ST- uses/shares the Python 3.9.6 installed with the Xcode command line tools
2. HW- uses the Python 3.11.9 from Homebrew embedded

Best regards,
Kazzz-S

[klayoutmatthias]

@Kazzz-S Many thanks for the new DMGs. Let me know if they do the job and I will place them on the server.

Best regards,

Matthias

[lukasc-ubc]

This version works for me: HW-klayout-0.29.0-macOS-Sonoma-1-qt5MP-RsysPhb311 Thank you

[Kazzz-S]

Hello @klayoutmatthias,

Please place the new three DMGs uploaded here on the server.

I'll build the HW-*.dmg from the next maintenance release using the (qt, ruby, python)=(qt5macports, sys, hb311) parameter set.
I'll also update the contents of the Homebrew-HUser-ReadMeFirst.txt accordingly.

Best regards,
Kazzz-S

---

Side Notes on the Lifetime for Qt 5.15

See https://www.qt.io/blog/qt-5.15-extended-support-for-subscription-license-holders

[klayoutmatthias]

Dear @Kazzz-S and @lukasc-ubc,

Thanks @Kazzz-S for the update!

I have placed the files on the server. I invented this description, maybe you can check if that makes sense:

Thanks, and best regards,

Matthias