Got a new laptop.

The old one's max resolution is 1336x768.

The new one goes up to 2880x1800.

Ubuntu Studio 22.04 ditched XFCE in favor of KDE Plasma. The global zoom feature works very well -- apps are super crisp, almost like Retina.

Except... Pd's Tcl GUI scales some elements, but not all. Menu text is scaled but window sizes are not. Patch objects are not scaled -- zoom = 2 helps, but then the patch window (which had been big enough) is now too small to see the same contents as on my old system. Basically you can't make patches that look good in both yesteryear's typical resolution and modern displays.

I'm just wondering how people deal with this.

1. Use zoom and accept that the patch windows will be too large on other systems.

2. Or, set the system to lower resolution (affecting the clarity of all apps -- I've tried this, everything looks like jpg, it's kinda gross).

3. Or, use Purr-data because they've actually done the heresy of replacing the GUI. (Also checked this out, but it seems purr-data handles [declare]s differently...? Gaaaahhh...) But this isn't quite a realistic option in the near term because I don't want to confuse the students with only a month of class left.

Any other thoughts?

Will Pd-vanilla ever unshackle itself from Tcl?

hjh

I’d say plugdata is the future of pd.
Still in beta but has a great juce based vector gui like max , can run as a vst and standalone .

@gentleclockdivider said:

I’d say plugdata is the future of pd.

I've used it -- it does look good. I might go with the standalone next time I teach this "interactive multimedia" cycle. (Although Gem rendering seemed not to take place in the standalone.)

Pd vanilla is likely too entrenched in the past to ever update. You can see this whenever anyone proposes a moderate change in UI and the old guard chime in with "but we like it the old way."

The Tcl/Tk GUI is well tested and stable, but it is not even close to modern.

hjh

well
tbf the 'old guard' is slowly migrating pd away from being reliant on tcl/tk and developing a non-tcl/tk-specific gui message format so that something like gtk or qt might be used
could be done less 'incrementally' though imo.
my issue isn't so much with how dated tcl/tk is, but the general dismissiveness of its devs regarding fixing bugs/unwanted behavior.
a few years ago I was trying to get them to fix a part of the 'help' menu being disabled on MacOS and their initial response was basically 'you can work around it/maybe it's on the apple side so whatever' even though we COULDN'T work around it:
https://core.tcl-lang.org/tk/tktview/7185d26cf4121c526718459f5fd239e6d777fdee

this kind of response/attitude is frustrating to see from devs, (even though it might only be a handful/very small minority of them). And from what I've seen it isn't constrained to that issue. There's often a 'throw your hands up' attitude..

that being said, in the end they did consider it a bug and did fix it. If you want better support for high-resolution displays you can always see what the options are/what the support is like on the tcl/tk side.

but, it might be up to pd to render things differently/send different commands (and that might be the case w/ a more 'modern' framework as well) since all of the geometry is based on pixels. maybe it's possible to store some kind of flag and edit/save the window at a zoom size twice what it would be for a non-high-resolution display. When the window is saved it would store the view area as half of the current value (so the viewing area is the same on regular resolution as well). and when windows are opened they open to double the size of their saved value

@seb-harmonik.ar said:

well
tbf the 'old guard' is slowly migrating pd away from being reliant on tcl/tk and developing a non-tcl/tk-specific gui message format so that something like gtk or qt might be used
could be done less 'incrementally' though imo.
my issue isn't so much with how dated tcl/tk is, but the general dismissiveness of its devs regarding fixing bugs/unwanted behavior.

Thanks for the additional context.

What you're saying about Tcl devs' retrenchment is suggestive of a dying ecosystem... which, I don't really care, I'm not programming in it, but if it drags Pd down with it, that would be unfortunate.

maybe it's possible to store some kind of flag and edit/save the window at a zoom size twice what it would be for a non-high-resolution display.

It would almost be enough only to scale window coordinates according to the zoom level set in pdsettings (except for users who set zoom < 1 to fit more objects in).

hjh