@User,a 'software' question. Since linux is slowly switching from Xlib to Wayland do you have a roadmap for that? For Xschem: it draws directly using Xlib calls, and uses Tck-Tk for UI interface (menu, dialogs etc) For the Xlib phase out the easy path for xschem drawing is to switch to Cairo graphics, this is already done in xschem to draw text and images, so swicthing the remaining primitives (lines, polygons, etc) to cairo is easy (i expect a performance degradation however). For the Tcl-Tk UI i don't know, as i don't see any plan for migrating to Wayland. This is sad since in 20 years the Tcl API has been really stable and today xschem compiles and runs fine with all tcl-tk versions from 8.6+ back to 8.4 which was used ~20 years ago. See any gtk project and how much work has to be done any time a gnome/gtk dev wakes up in the morning and changes/deprecates random parts of the core C API. I believe Magic also uses tcl for many UI parts so just curious what are your thoughts.

I was under the impression that X11 had been coexisting with Wayland for years. I converted both xcircuit and magic to Cairo, but for both of those, that's just the rendered window, and Tcl/Tk takes care of the window arrangement, pop-up menus, etc. At any rate, I'm assuming that there will always be some sort of compatibility level for X11, or about 95% of anything with a GUI written for Linux will break immediately. I don't think anyone could make a switch to native Wayland without such a compatibility level.

... or there is Qt. I am pretty sure it's the best option since it's crossplatform with 3D acceleration support.

@User Qt is built on top of Wayland/X11, right? But it is faster than directly use them, right?

@User Thanks, yes i also think there will be a loooong time before xlib (direct or emulation layer) disappears from mainstream systems. For the time being, yes, there is a 'XWayland' emulation layer (kinda similar to the XQuartz X11 emulation on MacOS) so i don't see near/middle term problems. @User yes there is Qt (as well as Gtk) but: 1. Qt is C++ so linking it in a C project is probably overkill 2. both Qt and Gtk are monsters, giant spaceships adding tons of library dependencies, I dont know much about Qt, may be its API is little more stable than gtk. For Gtk i know enough about it to stay away as far as possible, due to the Gnome/Gtk developer habits of continously changing the core API between version releases; this happened for Gtk1, Gtk2, Gtk3, Gtk4. If you start working today on Gtk4 you will probably release when Gtk5 is out and you will have to rewrite lot of your UI again. Performance-wise i don't know if 3D acceleration really helps speeding up 2D vector graphics programs. If you have to draw 128 OpenGL triangles to draw a decent thick line with rounder endcaps may be (at least on some low-end GPUs) there is no benefit at all.

Its faster because you can use GPU for rendering of schematic. It outperforms what cpu can do by long shot. + stable API + good code + plenty of ready to use code

@User @User I think Klayout is using Qt as its core, and that would make it faster in rendering layouts in comparison with the Magic, I guess?

It's worth to carry C++, actually it's the other way around. Its worth because of C++

But it is using Qt, right?

yes

Also Qt is backward-compatible I guess?

Not really, but API is pretty stable

@User

3D rendering for 2D is insanely better perfomance if you are drawing 10+ triangles

You missed the point. The issue is that to replace a single XDrawLine() call i need at least 128 OpenGL shapes to to the same thing with a barely acceptable quality. So i am not sure what is the fastest way. Moreover consider that almost all X11 Xservers already do OpenGL 'glamor' acceleration where it makes sense (for example blitting areas / simple shapes). I already did experiments with Cairo using OpenGL backends and the final result was slower than directly calling Xlib. This is true on low-end GPUs, where speed is important. High end GPUs like Nvidia are fast anyway so who cares. The bottom line is: Yes, OpenGL is insanely fast if you are doing 3D (blending/projections, 3D transformations/texturing) but for 2D vector graphics i don't know.

No, you can use ready-to-use Qt functions for this. I strongly encourage you to take a look at Qt for anything GUI related. It's not as simple as XLib/Cairo, but worth it overall because code base becomes much cleaner.

@User xschem is a c89 project, it builds on any machine from ARM boards to SunOS / Sparc, IRIX, and more. Using Qt requires to build xschem as a C++ project. Not big deal as most of C syntax is C++ valid, but I don't want to raise the minimum requirements to build Xschem to C++23.

I mean, why not? Seems that apps with good GUIs have much better popluarity (KLayout vs Magic VLSI) as they are simple to use.

@User what are you trying to do with Pex spice exactly? How does that relate to the UI toolkit? because for xschem the UI toolkit is just doing 'the stupid things' like handling menus, dialog boxes, event handling. Simulating a design with PEX extracted elements is possible in xschem, but i don't see what this has to do with the GUI toolkit.

I have a Layout. I extracted a PEX SPICE netlist. I want to do a simulation where all cells from PEX SPICE replace cells in the existing testbench. If I just replace the subcktt in generated TB netlist, I can't really do it, since the pins order is different. There is no automatic way to do it. If the xschem was written using C++ and Qt I would implement it myself. If xschem is implemented using Xlib and C89 I am simply going to avoid working with it. Globally this means that (possible) devs will be less motivated to contribute to Xschem due to it's choisces. See the problem?

Adding buttons or menus is actually simpler than you might think. This piece adds a 'test' menu with a couple of entries:

## Add a custom menu in xschem

## Create a menu entry 'Test'.  '.menubar' is xschem's main menu frame.
menubutton .menubar.test -text "Test" -menu .<http://menubar.test.menu|menubar.test.menu> -padx 3 -pady 0
menu .<http://menubar.test.menu|menubar.test.menu> -tearoff 0

## Create a couple of entries
.<http://menubar.test.menu|menubar.test.menu> add command -label "Test entry 1" -command {
    puts Hello
}
.<http://menubar.test.menu|menubar.test.menu> add command -label "Test entry 2" -command {
    puts World
}

## make the menu appear in xschem window
pack .menubar.test -side left

by the way the whole UI is done in Tcl, so you can rewrite completely the interface without recompiling the program. The choice of Tcl was done because in one shot you get the UI and a scripting language embedded in the application. Any user action is scriptable. so repetitive actions can be easily automated. And yes, this was true 30 years ago and still holds today.

@User: I totally agree with the assessment that Qt and Gtk are "monsters". I have avoided both of them for that reason. Also agree with your comment on using OpenGL for 2D. . . I did this once in xcircuit and decided that it was not going to happen (for the same reason you mention: Line drawing is a non-trivial operation and results are poor. Also drawing text is non-trivial). I should say that OpenGL works well for magic, but that's because its basic operations are drawing rectangles with overlaps, stipples, and transparency, which OpenGL is good at. But then Cairo is similarly good at that, and also good at line drawing. Both OpenGL and Cairo have their little system-dependent quirks that have to be worked around. I had one computer once that rendered my magic layouts upside-down, and I could never figure out why.

Okay, I see why it was done the way it was done. Much better than I thought.

@User simulating part of your testbench with PEX netlists is easy. You can easily fix the port order in xschem so it matches the pex netlist, this is explained in this video. You can also read the 'Pin ordering' section in the manual page about attributes. In a nutshell, you can explicitly set the order in the symbol format string by using the @@ prefix and the name of individual pins, like in:

format="@name @@A @@B @@Z @symname"

or rely on the stored order of pins and use the following:

format="@name @pinlist @symname"

. the @pinlist will list the pins in the order they were created while creating the symbol. This ordering can be changed as explained in he manual. Next if you descend into one of these symbols and change the

type

attribute from

subcircuit

to

primitive

, xschem will not descend further when netlisting and will not expand the schematic, you need in this case to provide the pex netlist, by adding a

.include

line in the testbench. this video also explains the process.

OpenRoad uses Qt and it really isn't that hard to handle the dependencies (ie OpenLane builds OR). Using Qt != using opengl. You have different apis depending on what you are doing.

@User I agree, plus OpenGL by itself is a plethora of versions (plus EGL variants) each with its own list of capabilities and features. Doing anything portable is extremely difficult (this is why 'universal' toolkit are millions of lines of code). And also i routinely use Vnc / Ssh tunnels forwarding graphis thru it, All things that need a fallback rendering method anyway. These connection methods are good also for discovering problems. Sometimes I see graphical artifacts in one case and not in the other. Portability is king.