How to make the outlet port "hot area" a bit larger?

ddw_music

About 20% of the time when I'm trying to drag a cable out of an outlet port, I end up moving the object.

This is getting really old.

Does anyone know offhand where to hack the hot zone size, so that maybe one does not have to have superhuman precision?

hjh

oid

@ddw_music Control+ will make them twice as large...

I started having issues with this somewhere during 0.52 but never did before, could be I am getting old and/or lazy but it could be something accidentally got changed recently. Maybe the mailing list where the devs are would be a good place to ask? I assumed it was me.

ddw_music

@oid said:

@ddw_music Control+ will make them twice as large...

And then you can fit about 10 objects going down on a typical laptop screen, not enough to do anything interesting.

I started having issues with this somewhere during 0.52 but never did before, could be I am getting old and/or lazy but it could be something accidentally got changed recently.

Interesting that it isn't only me. Possibly somebody complained that they were getting cables when they wanted to move the object.

hjh

oid

@ddw

Possibly somebody complained that they were getting cables when they wanted to move the object.

I follow pd's progress on github and have never seen such a complaint, so I do not think that is it, but there could be a good number of us who just assumed the problem was with ourselves and not pd.

lacuna

not the only one. That is the reason, I am patching with zoom mode on small screen. Still missing the hot area by times.

Also wish we could just draw connections across multiple objects/messages by simply drawing the cable across them + pressing hot key.
Also wish we could grab a cable at one end to change connection.
Wish there was a shortcut to open objects-help.
Wish autocompletition-plugin would run stable (it has hiccups and even crashes pd when closing a window occasionally).

lacuna

@ddw_music said:

Does anyone know offhand where to hack the hot zone size, so that maybe one does not have to have superhuman precision?

searching sources for

mouse

I found in https://github.com/pure-data/pure-data/blob/20334410c20948f14f5c1d8ae5ed992717b83291/tcl/pd-gui.tcl

            # mouse cursors for all the different modes

[...]

            set ::cursor_editmode_connect "circle"

.
Then searching for

cursor_editmode_connect

I found probably relevant
https://github.com/pure-data/pure-data/blob/c4ae1bd8df436de15c0a80f303ae33b5f3569088/src/g_editor.c

  /* look for an outlet */
            else if (hitobj && (noutlet = obj_noutlets(hitobj)) &&
                ypos >= y2 - (OHEIGHT*x->gl_zoom) + x->gl_zoom)
            {
                int width = x2 - x1;
                int iow = IOWIDTH * x->gl_zoom;
                int nout1 = (noutlet > 1 ? noutlet - 1 : 1);
                int closest = ((xpos-x1) * (nout1) + width/2)/width;
                int hotspot = x1 +
                    (width - iow) * closest / (nout1);
                if (closest < noutlet &&
                    xpos >= (hotspot - x->gl_zoom) &&
                    xpos <= hotspot + (iow + x->gl_zoom))
                {
                    if (doit)
                    {

[...]

/* not in an outlet; select and move */

...Searching the sources for IOWITH
or better OHEIGHT
has this result among others:

https://github.com/pure-data/pure-data/blob/5462d1eae0ad9f139997d56d459c212e797d96be/src/g_canvas.h

* --------------------- geometry ---------------------------- */
#define IOWIDTH 7       /* width of an inlet/outlet in pixels */
#define IHEIGHT 3       /* height of an inlet in pixels */
#define OHEIGHT 3       /* height of an outlet in pixels */
#define IOMIDDLE ((IOWIDTH-1)/2)
#define GLIST_DEFGRAPHWIDTH 200
#define GLIST_DEFGRAPHHEIGHT 140

#define GLIST_DEFCANVASXLOC 0
#ifdef __APPLE__
#define GLIST_DEFCANVASYLOC 22
#else
#define GLIST_DEFCANVASYLOC 50
#endif

.

(Not sure how the apparently different size of inlets and outlets hot area is coded? Inlets appear to be 'magnetic'. )

Wish there was a shortcut to open objects-help.

Could belong here:
https://github.com/pure-data/pure-data/blob/90ad8005199605095e49dbbf1daf4f032211b7f4/tcl/pd_bindings.tcl

lacuna

@ddw_music said:

@oid said:

@ddw_music Control+ will make them twice as large...

And then you can fit about 10 objects going down on a typical laptop screen, not enough to do anything interesting.

With zoom mode on and changing font size to 8, objects are shrinking and the ratio between obejct size and io size changes.

EDIT:
and in pd-gui.tcl
https://github.com/pure-data/pure-data/blob/20334410c20948f14f5c1d8ae5ed992717b83291/tcl/pd-gui.tcl

you can edit the font size even smaller, which helps but ratios between GUIs and messages/objects actually get messed up:

# sizes as above for zoomed-in view
set font_zoom2_metrics {
    10 19
    12 26
    14 32
    20 38
    28 58
    44 88
}

looks like this with zoom in and font size 8:

whale-av

@ddw_music You can stretch horizontally by adding a fake argument...... e.g.

It throws an error...... but somebody out there knows what character (that doesn't show... like a space) can be used and doesn't throw errors. I have seen it done many times.
Or if an example can be found on the forum it can be analysed.
David.

oid

@whale-av said:

I have seen it done many times.
Or if an example can be found on the forum it can be analysed.

Those are probably just resizing the object with the mouse? I do not think there is a character you could use that will not cause an error with a [trigger] since it is rather picky about its arguments.

oid

@lacuna said:

Wish there was a shortcut to open objects-help.

That is simple to add through tcl, this plugin shows how

ddw_music

@lacuna "With zoom mode on and changing font size to 8, objects are shrinking and the ratio between obejct size and io size changes."

Hm, ok, that might be worth a try.

@whale-av "You can stretch horizontally by adding a fake argument"

The issue seems to be more with the height of the hot area. An object would need a large number of outlets for them to merge horizontally, and this seems to be unidiomatic for object design (and rightfully so -- too many outlets without args to space them out is just confusing and shouldn't be done often). I don't have a problem with hitting the wrong outlet out of several. I frequently have a problem with reaching for an outlet but getting the object for moving instead.

Btw oid is correct about resizing by mouse. I do this all the time, especially for "master control" triggers at the top of complex algorithms. There's no need for filler characters.

@lacuna ypos >= y2 - (OHEIGHT*x->gl_zoom) + x->gl_zoom

OHEIGHT looks promising as well.

hjh

ddw_music

Followup: OHEIGHT seems to make the mouse Y positioning more forgiving, and also makes the visible blob larger.

So I might end up adding a #define for OHEIGHT and O_VISIBLE_HEIGHT or such.

hjh

ddw_music

I'm going to try this for awhile:

            else if (hitobj && (noutlet = obj_noutlets(hitobj)) &&
                ypos >= y2 - (OHEIGHT * 2 * x->gl_zoom) + x->gl_zoom)

... adding * 2.

Oh, one more finding: Your mouse can be pointing at the hotspot and not activate connection mode!

But dragging from here does a rectangle-select, not a move.

hjh