DonationCoder.com Software > Screenshot Captor

Preferences UI accept / apply button naming & function

<< < (2/2)

mouser:
What I mean is simply this:

There are hundreds of checkboxes and options in the SC options dialog.  In order to have the Apply button enable after you make a change to one of them, I'd have to Enable the Apply button after you change any of those hundreds of controls, which means that I'd have to trigger an event time any of those hundreds of control get triggered, and that's simply not something I do.

cmpm:
I don't think Apply should grey out because it's not a permanent change.
Which gives me time to check and test if I like the changed settings.
You can hit Cancel to discard changes or Accept to keep them.

imho fwiw

cathie28:
EDIT:  Note that in working tools, like resize canvas, you make changes & there's a Preview button & an OK button to make changes permanent (which is also called Apply in many apps).  That probably sums up the inconsistency in SSC button names, depending on which screen or menu you're in.  I didn't realize that this topic would be controversial in the least or have much debate about unconventional button naming in Preferences.
End of Edit.

cmpm - you're correct, in that "previews" of changes shouldn't be "final" or gray out buttons.  It's a moot point, as mouser doesn't want to change it.  That's OK - it's his time involved to make changes & maintain it.

Strictly talking points, my OP was about the button naming vs function - compared to most professional apps' convention.  For most apps w/ such buttons, Apply means the final step in saving changes.  Often, they can be undone / reverted, by hitting Cancel - before you leave the screen.  

In this context, Apply & Accept generally mean the same thing to the avg person, but I can't recall seeing Accept used to save all changes vs Apply or Save.

If buttons just show what the changes look like (I have no idea what all options do that in SSC), that's usually named Preview or View Changes, not Apply.

Some high lighting or pop up (even momentarily), could easily be added to the final Accept / Apply button - or not, once clicked  to show it'd actually been clicked.
That  wouldn't require tracking events in prefs.  But clarity of buttons' function (naming) is more important.

tomos:
as said above I think the [Accept] button is normally the [OK] button - otherwise it's pretty much as normal for windows (here the dialogue for changing screen resolution):

Navigation

[0] Message Index

[*] Previous page