Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

I'm not sure where to post this. I hate to post anything in General since beta is like 5 versions ahead now. Razz

What I would like to see when you click File->Save or Apply in Options, is that after it saves or applies the changes they get grayed out until you change something again. This way I have a visual confirmation my changes are actually saved. I know this is no big deal and not a priority. I'm just saying it would be nice.

Posted: Sat May 03, 2008 2:38 pm

Or perhaps the "this thing has been changed" flag that's already used to mark what's been changed for the saving thread (so that it only writes out things that've actually been updated) be made visual? Lots of text editors do this, they put a * or something next to a file if it has unsaved changes. Whatever marker was used to show a setting had been changed since the last save would disappear once the save had been done (whether manually or by the background save thread).

Posted: Mon May 05, 2008 5:16 pm

Unfortunately I won't be doing anything like this any time soon. The rewrite of the Settings Editor in v2.2x was designed to minimize repainting the tree view in the settings editor. With your suggestion, the items in the tree view would need to be repainted in order to show the * when a setting changes (much like it is repainted to show a setting as disabled with the strikeout font). Since settings change a *lot* in a normal MUD session, this would cause the settings editor to get really slow again.

And really, this is just related to some of the reported problems with saving settings that have become hard to reproduce, and displaying a * and getting rid of it won't even necessarily tell you for sure that your setting was saved. All it would do is tell you if CMUD *thinks* that is it saved. If CMUD is working properly, then this feature isn't needed at all (your settings are always saved).

Right now, in the settings editor, if the "Save changes" button in the toolbar isn't enabled, then your setting is saved. If the Save button is enabled, then your changes haven't been saved yet. So there is already visual feedback for the setting that you are currently editing.

Wizard Joined: 17 Jun 2006 Posts: 1201

I'm not sure what you mean. It's it just a matter of enabling and disabling the buttons. I don't see where it is ever disabled. It's always enabled whether I have made changes or not, which is confusing. The same goes with Apply. It's always enabled. I don't see how this would slow down the client, because it's just standard to do this on any application isn't it? (Not trying to be rude! So don't take me wrong like last time) Very Happy

Posted: Mon May 05, 2008 10:28 pm

Maybe we are talking about different buttons, or maybe there is something really weird with how it displays on your computer. But here is what my toolbar save/cancel buttons look like normally (setting is saved):

And here is what it looks like if I type some text into the Value field to change the setting:

The first image shows the buttons disabled, and the second image shows the buttons enabled. Isn't this what you are talking about?

Wizard Joined: 17 Jun 2006 Posts: 1201

Ahhhh, no. I'm talking about the Save in File Menu and the Apply button in the Options Dialog. Sorry I wasn't clear as to which Save I was talking about.

Posted: Mon May 05, 2008 10:52 pm

Oh, OK. The File/Save forces a save of the entire package, so it's always valid to select that even if nothing has saved. I don't want to disable that menu option ever. And there isn't any easy way for it to know whether any settings have changed when displaying that menu option. When enabling/disabling menu options or buttons, the routine needs to be very fast because Windows calls the routine a lot when repainting menus.

The Preferences Apply button might be a bit easier to handle since that isn't embedded in a menu or toolbar (so it doesn't get updated by Windows itself). I have more control over the Apply button. Doing an "easy" job on this would be trivial...whenever an option on the page changes, the Apply button gets enabled. But it would still be really easy to trick it. For example, check an option to change it, and then check it again to change it back. As far as the database is concerned, that option has still be changed and still gets written to the database (and thus, Apply would still be enabled), even though you might consider that the settings haven't changed.

It's like going into a text editor and typing something, then saving. Then type something else and backspace over it to get rid of it...notice that the file is still marked as "changed" even though it looks the same as before.

So I'm just not sure how useful that would be. But if you think it's still useful, let me know...it would be hard to do that with Apply.