I suppose it's something to do with tcl/tk, but what?

cheers

@Nicolas-Danet Don't interpret "I'm happy" as "I'm happy and never want it to change."

I've looked into Jonathon's GUI communication interface and there is not too much to change within the sources, really. Just replace most of the sys_gui calls and add gui drawing details to the GUI itself. He has his approach documented in the Purr Data readme. This is after I had already personally gone through all of the GUI code to integrate the Pd-extended sizing and improve issues with IEM GUI draw order. In fact, a lot of the IEM GUI sys_gui calls are redundant and could be better refactored.

For example, the Purr Data g_bang.c sources do not send any custom tcl strings, just "update the bang with this color" and the drawing is done on the GUI side: https://git.purrdata.net/jwilkes/purr-data/-/blob/master/pd/src/g_bang.c#L35

I hope you are not already writing your own custom implementations of the built-in GUIS for your project. I would suggest we work together into porting Jonathon's gui_vmess approach first. I am also in the same boat having written custom implementations in CoreGraphics for iOS but I'd love to replace those with more built=in handling, ie. just draw/update the bang on the Obj-C side without the placement & interaction code.

UPDATE: I do not mean to "toot my own horn" in these responses. By stating some of the work I've done personally, I meant to show that effort was made on some of these points and they were not dismissed out of hand. Also, having spent some time with the code itself, I want to convey that some approaches are definitely possible and the issue is less technical (can we do this) and more organizational (what is the best way to do it and make it sustainable / future proof).

@danomatika said:

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

Thanks for the long and detailed post. A lot of the quotes that you're responding to came from me, so I wanted to start off by saying I really appreciate your taking the time to explain your perspective.

What you're replying to is about a year old. Some of my opinions (such as, the GUI frightening away new users) have softened a lot in that time.

I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon. The last couple of posts here are encouraging.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).

Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...

Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.

Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled). "Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.

WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.

hjh

@ddw_music said:

I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon.

I think most people agree with you, myself included. Tk is clunky but it's in the current code base and has been kept so far since it works, although admittedly barely in many cases.

The last couple of posts here are encouraging.

I know development is slow, but it's really working against inertia. Momentum has been growing the last years and that's mostly due to more effective collaboration to tackle some of these issues. I think finding a sustainable approach to the GUI is one of the largest ones, so is taking a while to grow.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)

Yup, you are totally right. I didn't mean to imply the Linux screenshot looked good since "that's the way it is" just more that it looks so much better on macOS since the screenshot is likely double the resolution as well.

I started using Pd on Windows circa 2006 then jumped to Linux for many years, then to macOS. My feeling was that Pd worked best on Linux but a lot of that has caught up as the underlying systems have developed but in some ways the Linux desktop has not (for many reasons, good and bad).

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).

That's a result of many of the forks adopting the "kitchen sink" monolithic distribution model inherited from Pd-extended. The user gets the environment and many external libraries all together in one download, but the developers have to integrate changes from upstream themselves and build for the various platforms. It's less overheard for the user but more for the developers, which is why integrating a frankly large and complicated external like GEM is harder.

I'm happy to download the deken GEM package because I know the IEM people have done all the craziness to build it (it's a small nightmare of autotools/makefiles due to the amount of plugins and configuration options). I am also very happy to not have to build it and provide it to other users but in exchange we ask people to do that extra step and use deken. I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners. There are some thoughts of improving it and feedback for people in the teaching environment has also pushed certain solutions (ie. Pd Documents folder, etc).

Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.

By "tracking" I am referring to a fork following the new developments in Pd-vanilla and integrating the changes. This becomes harder if/when the forks deviate with internal changes to the source code, so merging some changes then has to be done "by hand" which slows things down and is one reason why a fork may release a new version but be perhaps 1 or two versions behind Pd vanilla's internal objects, ie. new [soundfiler] right outlet, [clone] object, new [file] object, etc.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...

Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.

Hah yeah, I totally understand. My first contribution to Pd(-extended) was to find out how to disable showing hidden files in the open/save panels on Linux. You would open a dialog, it defaulted to $HOME, then you had to wade through 100 dot folders. Terrible! Who did this and why? Well it wasn't on purpose, it was just the default setting for panels on Tk, and I added a little but of Tcl to turn it off and show a "Show hidden files/folders" button below.

OTOH I have a colleague at work who's internal toolkit still uses Motif. Why? Well it still works and he's the only user so he's ok with it. I'd say that Tk also still uses Motif... but there are many users and they have much different expectations. ;P

Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled).

Ah yes, I forgot about this one. It wasn't rejected, just came at a time when there were lots of other things shouting much louder, ie. if this isn't fixed Pd is broken on $PLATFORM. I would say that, personally, your initial posting style turned me off but I recognize where the frustration came from. I also appreciate making the point AND providing a solution, so the ball is in our court for sure. I will take a look at this soon and try it out.

"Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.

Another approach would be to try to bring improvements to Tcl/Tk itself but the dev community is a little opaque, more so than Pd. However I admit to not having put a ton of time into it, other than flagging our custom patches to the TK macOS guy on Github.

WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.

As would I... we are preparing for a major exhibition opening in December, but I will have some time off after and I may take a stab at a technical demo for this (among other things) then pull in some other perspectives / testers. It has been an itch I have wanted to scratch since, at least Pd Con 2016 in NYC.

As a newcomer to Pure Data and the community, it is heartening to see users and developers coming together to figure out how to improve the state of the art. I can understand and appreciate both the perspective of experienced users who instinctively work around and grow accustomed to existing behaviors, and new users that encounter... unconventional behaviors and see them as warts that detract from the overall user experience.

Within a few days of starting to use PD, I had created a text file called wtf_pd.txt with 17 annoyances that immediately jumped out at me in terms of UX. I've now figured out how to work around most of them, but I would very much like to address these problems, hopefully by getting accustomed with the coding standards of the project, submitting some PRs, and getting buy in from the development team. A perfect example being the fact that I can't resize the graph-on-parent canvas size by clicking and dragging, but have to enter in values manually in the properties dialog. Feels like editing HTML/CSS in the early 2000s .

At the end of the day, I think what we need to do is continue the discussion and work towards fixing these little papercuts over time. While individually they may be small, collectively they have a significant impact on the overall usability of the program. I do recognize, this being an open source project with finite resources, that these types of fixes rightfully take a back seat to stability and more severe bug fixes. But having discussions like these at least allows perspectives of new users to be heard, and eventually (hopefully) addressed as development cycles become available.

I have so much enthusiasm for the future of PD because it's opened up a whole new paradigm for me as an artist and musician. It is my belief that there are many, many other artists out there who would come flocking to Pure Data if they recognized what it was capable of.

My goal is to help bring PD to a wider audience by continuing to put myself in the shoes of new users, and to try my hand at contributing fixes wherever possible.

@danomatika said:

That's a result of many of the forks adopting the "kitchen sink" monolithic distribution model inherited from Pd-extended. The user gets the environment and many external libraries all together in one download, but the developers have to integrate changes from upstream themselves and build for the various platforms. It's less overheard for the user but more for the developers, which is why integrating a frankly large and complicated external like GEM is harder.

Fair enough -- but, no GEM on Mac, I can't use it in class. And I couldn't use it at home either, because (a couple of years ago) it seemed that Purr Data had added something(?) to the Pd file format so that Purr Data patches could not open reliably in Pd-vanilla. It didn't take too long to realize that I have to pick one or the other.

I'm downloading Purr Data to try again. It's been probably 2 years now.

I'm happy to download the deken GEM package.... I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners.

I teach my students not to add a bunch of paths/libs in Preferences, and always to use [declare]

Ah yes, I forgot about this one. It wasn't rejected, just came at a time when there were lots of other things shouting much louder, ie. if this isn't fixed Pd is broken on $PLATFORM. I would say that, personally, your initial posting style turned me off but I recognize where the frustration came from. I also appreciate making the point AND providing a solution, so the ball is in our court for sure. I will take a look at this soon and try it out.

Yeah... the tone. I've made more peace with the tool and hope that my tone has softened somewhat. I think at the time, I had observed that the user forum (here) tended to respond to criticism of the interface UX more or less along the lines of a/ we just get used to it (hm, no, if the tool is clumsy, we should improve the tool) or b/ we like it this way (aka don't mess with existing users' muscle memory) -- which is fine if the behavior is more or less standard, but the behavior in question is not. And in fact, the first comment on the PR was to question whether my assertions about the right behavior were correct at all.

So... while I do understand that the community would get tired of people complaining without fixing things, there is a danger in that of appearing to circle the wagons and reject criticism out of hand. (I think some comments in this thread raised that risk as well -- some members' a-priori rejection of antialiasing struck me as a quite startling form of resistance to progress.)

Perhaps the true test of a UI is not how you feel about it when you're relaxed and have all the time in the world, but rather how you feel about it when you have to get something done quickly, under time pressure. Pd works, but it doesn't always flow.

Thanks again for the detailed thoughts --
hjh

@ddw_music said:

Fair enough -- but, no GEM on Mac, I can't use it in class.

I tried pd-l2ork version based on purr data and a fresh version Gem is included. But, under macOsX, Gem is very unstable and tricky recently... sometimes you need to change the window manager in [gemwin] abstraction to fit the machine hardware etc... Strangely Gem in pd-l2ork doesn't work with my Windows, so it's really annoying for class. That's why I am using ofelia abstractions in class which are simple but works everywhere (Windows/OSX/Linux).

@link said:

Within a few days of starting to use PD, I had created a text file called wtf_pd.txt with 17 annoyances that immediately jumped out at me in terms of UX. I've now figured out how to work around most of them, but I would very much like to address these problems, hopefully by getting accustomed with the coding standards of the project, submitting some PRs, and getting buy in from the development team.

Do you have a Github account? You can open an issue and list all of your "paper cut" annoyances together.

Another approach is to bring the your list to the pd mailing list, then we can open an issue and bring the discussion there.

Last, if neither of those work, send me your wtf_pd.txt...

A perfect example being the fact that I can't resize the graph-on-parent canvas size by clicking and dragging, but have to enter in values manually in the properties dialog. Feels like editing HTML/CSS in the early 2000s .

Yup. Resizing to the object boxes was only added a few years ago but it would be great to have the same for GOPs.

@ddw_music Your single select drag and resize behavior bug fix is merged. Thanks!

UPDATE: A note from Miller on the pd-list:

Meanwhile merging the no-select-text PR - I meant to do that earlier but somehow missed it.

@danomatika Yes, I have a github account and I am planning on opening several issues. My plan is to let my initial impressions soak for a bit before I submit the bug reports; I want to make sure I'm touching on the most pressing issues and that I'm not missing anything obvious first. Thank you for the affirmation.

@60hz said:

I tried pd-l2ork version based on purr data and a fresh version Gem is included. But, under macOsX, Gem is very unstable and tricky recently...

OK, maybe I'll check a more recent Mac version.

I did have to advise one student to change [gemwin].

That's why I am using ofelia abstractions in class which are simple but works everywhere (Windows/OSX/Linux).

Yes, I remember those. They are truly impressive!

Unfortunately, I had to give up on them because of the lack of pix_ filters. I had started on an [of.shader] abstraction -- and actually got some basic shaders to run successfully! -- but something in my modifications to support this ended up breaking the behavior of multiple drawing chains. That is, I saw buggy behavior in my branch, but when I opened the same test patch using your branch, the bug disappeared. At that point, I had to decide that I don't have time to debug this (and, even if I did debug it, that would mean creating and maintaining a library of shaders, which... let's look in the dictionary under "time sink"...). So... back to GEM. I wasn't super thrilled about that (Ofelia seems more modern in a lot of ways) but teaching load and paperwork are increasing and I haven't been able to work on any of my own music for the last three months, no way I can carve out time for a huge project in an area I'm not even expert in.

@danomatika I did see the e-mail that the no-edit-on-move has been merged. Thanks!

Now, wait for Purr Data to catch up which is probably not a simple merge.

hjh

Just wanted to mention that I thought I saw that the edit-object-text-after-moving behavior just got removed.

Also this might be a GitHub or dev list topic but imo the main process shouldn't have anything to do with anything from the gui, including object/line geometry. The only thing it should be concerned with is audio and message processing, and the bare minimum info necessary to accomplish that.
So the main process would get info on which connections are made or removed, and what order the inlets and outlets are in but that would be it.

@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason. It seems like a settled issue, but sometimes we need his perspective as well...

@danomatika I remember someone giving some reason for reverting but still feels like a strange decision imo.
Maybe there should be some option/preference..
edit: ah, I see in the thread you make the same suggestion..

@danomatika said:

@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason.

From the comment in the source code, it seems that some users frequently do:

1. Ctrl-D to duplicate an object.
2. Mouse move.
3. Retype immediately into the object box.

... which, with the "no-edit" change, requires an extra click.

(My suspicion here is that "some users" = only Miller Puckette, but anyway.)

In github, I had commented two months ago that this really should be a user preference.

Now, granted... unpaid open source project, volunteer development, a couple of months inactivity on a non-critical issue is not at all surprising. So I wouldn't read anything into non-response.

It may be helpful for other forum users to comment on the github issue. Where it stands now, in github, is that there's MSP's view (which looks to me like "I want mouse-move-edit, and it's my project"), one grumpy user (myself) strongly opposing it, and a couple of votes in favor of a user preference. Because it takes developer time to add a user preference, it may require input from more users -- currently there's not enough demand for them to take the time, but if 20 users ask for the same change, then that's different.

hjh

@ddw_music said:

In github, I had commented two months ago that this really should be a user preference.

Actually it looks not crazy-difficult to implement that myself. I can't prioritize that project so it might take a little while, but I think I see the main code bits to take as models.

hjh

@ddw_music I might take a look at this and add the preference to pd-next too, if it isn't accepted. after all it's just an aesthetic/editing thing that doesn't affect the objects or patch format at all..
I think another option would be to have a keybinding to edit currently selected object(s?), since the users who want to edit object text after ctl-d need to use the keyboard at that point anyways