Just wanted to thank you guys for the 1.0 Boolean Assistant tool! What a nice feature 
Thanks!
4 Likes
OOh where is this little gem hiding?
Dāoh found it |c:
OH Brilliant addition! stops me from alt Zāing a lot.
Thank you!
@Rick When you select more than two objects, the Boolean Assistant is no longer availableā¦although the boolean functions are: Bug - or āDesign Featureā?
That is handy . Gives a quick check before commital
āWeldā will still be available, but the other Boolean tools operate on 2 shapes, so the selection of more than 2 objects grays the selection and should not present the Boolean Assistant, as these are not a valid operator at that point. Redirecting...
Gotchaā¦OK. Behaving as designed, then.
Another question on its behavior:
If you mouse over the boolean options (no click), the image changes to show you the results of that operation - which is terrificā¦but when you mouse OFF of any of the options, it doesnāt return back to originalā¦you need to close the dialog to get rid of the mouseād over effect. That behavior is a little unorthodox - I would expect it to only āstickā if I click.
Thatās on me - If you click āCancelā it reverts everything, so I didnāt see a big need to have it revert while you were in there. It also only does the hover preview if the shapes are āsimple enoughā. If it thinks itāll take a long time, it waits for you to click.
1 Like
Interesting. Personally, I think I would prefer consistencyā¦If it displays on hover, Iād want it to revert on hover-off. Just my (not always humble) opinion. Great feature, BTW.
1 Like
The idea was to make it as intuitive as possible for new users. If you hover over a button and see the effect you want, then move to click āOkā and it reverts, that would probably be unexpected, and frustrating. What Iāve done instead is added a new button called āResetā that looks like the Undo button, and when you hover over that, it resets the shapes back to normal, so you can easily see the non-boolean inputs now.
I actually tried it your way, and added code to make it so the buttons āstuckā when pressed (after clicking, no more hover preview) but that felt awkward. This one feels good, and is pretty intuitive - hopefully it strikes the right balance.
That sounds good. Is there a beta where I can try it out?
No, but weāll have a patch out shortly.
Iām sure you have more important fish to fry than to think about thisā¦but I guess I donāt and the more I dwelled on it, the more I wanted to voice an opinion. Iām sure what you have coming is going to be great (like everything else), but Iād like to argue this point a little bit - just from a programming perspective.
The buttons that you have in the dialog are really fancy radio buttons (theyāre not command buttons because they donāt actually commit the action) with a preview window. Radio buttons do not usually take effect on mouseover (even in preview). If there is mouseover, itās usually textual, and is always temporary until you mouse off. In most dialogs Iāve seen, you need to click the radio button to set the option and see it in the preview window (and clear the previous selection)ā¦then pressing OK/CANCEL either applies the option or regresses.
I like the āResetā option (I guess really, āNoneā), as the fourth radio button optionā¦so you can get back to the original without having to cancel out of the dialog and return.
Itās the standards thing thatās got me uncomfortable with the dialog. I think it would be more intuitive to have a strong 3-dimensional representation of raised and depressed buttons (a defined radio button action) and probably not have the mouseover at all. As much as I like the mouseover, the behavior is non-standard and confused me. Even if we had the mouseover influence the preview, the fact that the mouseover doesnāt go away when you leave the button is also non-standard for mouseovers. So, in effect, itās doubly non-standard.
I donāt expect anything to change because of this, itās just my opinion. Thanks for listening. You do a great job of creating a really useful product!
- Gary
@LightBurn Ooopsā¦I just loaded the latest version and saw how the problem is resolvedā¦and Iām going to lobby even harder to change it (sorry!)ā¦
Hereās what Iām seeingā¦can you tell me what function will be applied when I press OK?
If you think the answer is Union, you are incorrect. This is the Difference!
How? I CLICKED on Boolean Union, the blue reticle surrounded the Union option. I moved my mouse and it happened over the Difference on my way to the OK button. The blue reticle is showing that Union is selected, but the preview is showing Difference.
When I press OK, the Difference is applied - even though the Union option (radio button) is selected.
I REALLY think you need to either eliminate the mouseover (even though I really like it), or undo the mouseover impact when mousing off - AND - treat the buttons like radio buttons and insist that people click them to get a result when they click OK.
- Gary
Itās interesting how youāve been able to take something I was quite proud of and made me regret having created it at all. :-/
Iām going to make the hover update the button state to reflect whatās active. Iām not going to change it beyond that, regardless of how strongly you feel Iām breaking UI conventions, because so far youāre the only one complaining. I have heard your complaints and they are noted. Move on with life.
@LightBurn No! I had no intent to make you feel regretful! I love the featureā¦have NEVER seen it in any other product and think itās brilliant. LOTS to be proud of. I just want to help make it as useful (and non-confusing) as possible. I know you have PLENTY to do without me ācomplainingā. Iām just trying to help (in my own strange way).
Peace.
What you were seeing (the blue box) is the keyboard / mouse focus, NOT the last operation performed. Iāve altered the code so those buttons now āpressā and hold, so the whole button turns blue, and this happens on hover OR click. If you hover (or click) the reset button, all buttons are cleared.
The intention of the hover is to help gun-shy users, because for some reason people are reluctant to click things, scared theyāll break something. I understand that this is not standard behavior, but thereās plenty of standard behavior in OSās that is infuriating, so Iām perfectly happy to break it when it makes sense.
Standard behavior in windows, for example, is to allow the mouse wheel to scroll list items, as well as to scroll choices in a drop down box. In the last update, I disabled the mouse-wheel scrolling of the cutting mode (Line/Fill/etc) in the cut list, because it was too easy to do it accidentally when you meant to scroll the list. This was requested by a couple dozen people at least, despite breaking standard UI conventions.
Itās a bit like writing - A good writer understands the rules. A great writer understands when itās appropriate to break them.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.