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

cheers

@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