Just wanted to thank you guys for the 1.0 Boolean Assistant tool! What a nice feature Thanks!
OOh where is this little gem hiding?
D’oh found it |c:
OH Brilliant addition! stops me from alt Z’ing a lot.
@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. Modifier Tool - LightBurn Software Documentation
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.
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.
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!
@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.
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).
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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.