Gumball scale handle too big

I have an issue with the gumball because the scale handle it is located at the end of the selected line where also is a dot and it is impossible to select the end dot because of the gumball scale handle. Know somebody how to make the scale handle of the gumball smaller?

1 Like

press CMD while you click on the handles, it lets you resize it.

Oh yes! Thank you. It is working this way. But I need to press the CMD key every time I want to rescale, it is there a toggle or a preference setting to remember the scaled position?

the initial scaling depends on the size of the objects and it remembers the rescaling only on objects from a curve up to anything, but not on temporary selections unfortunately also not groups.

maybe that would be an idea for the upcoming versions. @dan how about remembering the handle scale on groups? or even better having fixed handle lengths which do not resize at all as an option at least? for big objects that would be a huge advantage.

(Whoops, sorry for the slow update…this one slipped off my radar.)

This is tough to do for groups and I don’t see a way forward. Persistent Gumball data is stored on an object’s user data. Groups are not objects, they are basically just selection sets, so there’s nowhere to store the data. (Each object in the group still carries their own persistent Gumball data though). Even if we were to get this working, this Gumball data would get obliterated when the Ungroup happens. The only solution right now is to use blocks for grouping instead; blocks are a separate object type and can carry a persistent Gumball data.

or even better having fixed handle lengths which do not resize at all as an option at least?

This might be do-able. Can you explain more how you would envision “toggling” this Gumball behavior? A hotkey? Or?

the selection also has to be stored somewhere, if its not so easy amending this at the selection data, maybe creating an invisible null object could work. just an empty skin which can store the data. obliterating the gumball data when ungrouping would be a fair and logic consequence, so not a problem at all, if needed it could still store the null object till purged, remembering the id’s and reassociating the gumball data when grouped again, but thats just playing around.

or even better having fixed handle lengths which do not resize at all as an option at least?

thinking about it i would not even use any hotkeys, it pretty loaded already, maybe simply using the handle lines, they currently only serve as indicators anyway, why not using them also functionally.

I wish it were that easy. The null object is not elegant and could introduce other downstream issues. We can’t really hang it on the document because it has to survive copy/paste from document-to-document.

Don’t get me wrong, I can see where this would be useful, but I don’t see a viable way forward given how we’ve architected this, unfortunately.

why not leaving the selection data at each of the objects involved user data, its just a few numbers. including a selection id and the id of the other objects meaning it will only call up the gumball data when all objects are selected again. to keep the data low of course the id and the reference data will be created only when the gumball of a selection itself gets moved.

i am not quite sure what you expect from me, its not that i dont like to be creative but i guess not knowing programming at all, i am probably the least person to ask…

something else involving selections, one idea which popped my mind, when i use filled edge as an example it remembers the last edge selection which i optionally can use. would be nice if this would be also permanently available for point selections in one object and that selections get a reference id which i can rename. that would save a lot of time when i adjust surfaces. but thats off topic and should be maybe split if you consider this interesting.