MUSHclient global prefs migrated from Registry to database

Posted by Nick Gammon on Sun 22 Feb 2009 02:34 AM — 19 posts, 79,023 views.

Australia Forum Administrator #0
There have been numerous requests in the past to have MUSHclient not keep its global preferences in the Windows Registry. There are a number of problems with the Registry, one being that it is hard to move a MUSHclient installation from one PC to another without a lot of mucking around saving and restoring Registry values.

Now that SQLite support is included in MUSHclient, it seemed a good time to revisit this.

Version 4.40 now moves the global preferences, and window locations, from the Registry to a SQLite database. To help understand how this works, I will describe below how this is implemented.

First, we need to decide where this global preferences file is going to be found. Obviously, storing its location in the Registry would defeat the purpose of these changes.

MUSHclient now tries this strategy to find the database file:

  • It looks first in the "startup directory". This is the directory it finds itself in when first invoked. You can alter that by making a shortcut to MUSHclient.exe, and setting the "Start in" location in the shortcut properties.

    The reason for doing that is that you can have custom global preferences by simply having different startup directories. For example, one for you and one for your brother or sister.

    It looks for the file "mushclient_prefs.sqlite". If found, this file is used for the preferences database.
  • Next, if that file is not found, it looks in the MUSHclient application directory. That is, the directory that MUSHclient.exe is actually located. This lets you have a single global preferences file, even if you use different startup directories.
  • If the preferences file is still not found, it is opened in the startup directory (and created from scratch).


If the preferences file needs to be created, three tables are created in it:

  • control - for various top-level parameters, like, the order of the columns in the trigger list.
  • prefs - global preferences
  • worlds - the location of the windows in the various world files as they are opened.


Next, existing global preferences (if any) are copied from the Registry to the database. That way your existing preferences are not lost.

However the other things stored in the Registry are not copied over, for simplicity. Thus you will find that your world windows will revert to their default positions, the columns in the configuration windows will revert to their default, and so on.

You can find the location of the preferences database by doing GetInfo (82). You could open the preferences file yourself to change global preferences if you wanted to (using the sqlite3.exe program you can download from the SQLite web site, or by doing it in scripting).

For example, you can look at the preferences like this:


sqlite3 mushclient_prefs.sqlite
 
sqlite> .mode csv

sqlite> select * from prefs;

AllTypingToCommandWindow,1
AlwaysOnTop,0
AppendToLogFiles,0
AutoConnectWorlds,1
AutoExpandConfig,1
FlatToolbars,1
AutoLogWorld,0
BleedBackground,0
ColourGradientConfig,1
ConfirmBeforeClosingMXPdebug,0
ConfirmBeforeClosingMushclient,0
ConfirmBeforeClosingWorld,0
ConfirmBeforeSavingVariables,0
ConfirmLogFileClose,1
EnableSpellCheck,0
AllowLoadingDlls,0
F1macro,0
FixedFontForEditing,1
NotepadWordWrap,1
NotifyIfCannotConnect,1
ErrorNotificationToOutputWindow,0

... and so on ...

sqlite> .exit


An example of changing a global preference offline would be:


sqlite3 mushclient_prefs.sqlite

sqlite> UPDATE prefs SET value = 1 WHERE name = 'EnableSpellCheck';

sqlite> .exit


To discard all global preferences (which is like reinstalling MUSHclient after removing it), simply delete the mushclient_prefs.sqlite database. That forces it to be recreated. However if you still have preferences in the Registry they will be used as the basis for recreation.

So, to totally revert to defaults, do this:

  • Close MUSHclient
  • Uninstall MUSHclient
  • Delete the file mushclient_prefs.sqlite in the MUSHclient executable directory, or the MUSHclient startup directory.
  • Reinstall MUSHclient


Australia Forum Administrator #1
The fairly extensive changes to the way preferences are handled will probably result in some teething problems. Please let me know if you have any. ;)


One of the intentions of this change is also make it simpler for MUD admins to release customized versions of MUSHclient, complete with pre-configured world files, and window locations setup in advance. Previously this would have been very hard without changing the Registry. Now it should be easy.
Australia Forum Administrator #2
Two things are still saved in the Registry, principally because they are done by the internal libraries and not directly by my code:

  • The Most Recently Used (MRU) file list - which show a list of recently-opened files in the File menu.
  • The locations of the toolbars. So for example, if you drag the toolbar around, the new location is saved in the Registry, not in the database.


Netherlands #3
I think this might cause havoc with Vista and higher when used in the typical 'install under Program Files\MUSHclient' method. Maybe I'm wrong - I don't use Vista nor am I awake enough to read your entire post in detail.

Vista likes to virtualize directories in Program Files when it finds out applications like to write to their own installation directory, and mirrors things in 'Local Settings\Virtual Store' or something like that. However, while I disagree with the execution of the feature, the basic idea for that makes sense. Applications shouldn't write to their own directories anymore for user-specific matters unless installed in a stand-alone method.

So, since I am not sure how MUSH differentiates between a stand-alone ('traveling') installation and a normal one, might I suggest using a check on being located under the users %PROGRAM FILES% directory, and if it is there, to use %APPDATA%\MUSHclient\prefsfile.sqlite ? It seems like a nice plan with Vista out and newer stuff on the way to try and keep such new operating systems happy.
USA #4
That would defeat the whole portability this was supposed to create, as you would have to track it down each time from each user's appdata folder.

-Onoitsu2
Netherlands #5
.. No. As I said - when run from Program Files. Eg.. non-portable installation. If you want MUSH to be portable, you wouldn't install it in Program Files in the first place.

Program Files? %APPDATA%\MUSHclient\prefsfile.sqlite
Elsewhere? %MUSHCLIENT% directory.
USA #6
While we are at it, can we store world files (and anything else that MUSHclient needs to write to) in a place other than Program Files, perhaps based on the same scheme Worstje is mentioning? The reason for this is that an increasingly larger number of users are using Vista, and it's becoming very commonplace to see questions on the MUD I play asking why they can't save their world files.
Netherlands #7
Well, for as far I know, the purpose of %APPDATA% has always been to provide a place for applications to store user-specific data that they do not need to take notice of. E.g. the under-the-hood stuff. Preferences come to mind, cached datastuffies, etc. World files would logically belong under (My) Documents, or some special subfolder.

Don't get me started on that subject, btw. Not only does stuff keep moving around with every other version of windows, it also keeps changing names. Drives me nuts, and as such I simply use C:\Files. Aah. :)
Australia Forum Administrator #8
Don't get me started on Windows ... :)

I recently found that Vista has decided to rename its default fonts that everyone uses, so if a Vista user sends a Word document to someone who has a Mac, they won't have the fonts (Helvetica or something that everyone uses). Their new names are Constantia, Corbel, Calibri, Cambria, Candara, Consolas, I think.

So that is a pest if you don't have Vista, *and* Microsoft don't make them available from their site, *and* they serve a "take down" notice on you if you try to publish them elsewhere. Oh well.
Australia Forum Administrator #9
Well I tried it on a fairly fresh copy of Vista. By default MUSHclient had its working directory set to:

C:\Users\nick\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\MUSHclient\

Pretty long-winded name, huh?

Anyway, that was where the prefs database went, so I suppose that is as good a place as any.

BTW I don't suppose anyone knows what "Desktop Windows Manager" is? That is using 64 Mb of memory and my hard disk is going crazy.

I don't know what it thinks it is managing, but I remember when Windows 3.1 only needed 4 Mb of RAM to install. Now a single part of Windows uses 64 Mb. Plus, another 18 Mb for Windows Explorer, and another 17 Mb for Windows Sidebar.
USA #10
http://en.wikipedia.org/wiki/Desktop_Window_Manager


It's the Bloatware that gives you the Aero interface.
Australia Forum Administrator #11
You know, it's kind of peaceful running Ubuntu. These 64 Mb applications that seem necessary under Windows don't exist. The OS runs smoothly and efficiently. Plus, MUSHclient works pretty well under it too. :
USA #12
Right, cuz Gnome isn't a bloated piece of wonky junk either. ;) Same function.

(I prefer XFCE & Xubuntu.)



Netherlands #13
.. wait. You are placing the prefs in the Start Menu?

(And don't get me started on those fontastic idiocracies, either. Already slammed my face into the wall due to that once.)
USA #14
Obviously too late for the 4.40 release, but have you considered having the location of the pref's db being specified either (a) on the command line or (b) in the world file itself. Haven't thought thru the implications of that, but (b) seems like it might solve some problems without having to mess with the shortcuts.

Daesilme / Dan
Australia Forum Administrator #15
Quote:

You are placing the prefs in the Start Menu?


Me? I'm placing the prefs file in the default startup location that Vista assigns a newly installed program. Maybe it is time to revisit the installer.

Quote:

the location of the pref's db being specified either (a) on the command line


I was hoping the application would behave in a reasonable way without having to use command-line arguments. Although some optional behaviour could be done that way.

Quote:

(b) in the world file itself


There is a chicken-and-egg situation here. It uses the global prefs to work out where the world files are stored.
USA #16
Quote:

There is a chicken-and-egg situation here. It uses the global prefs to work out where the world files are stored.


I could be remembering wrong, but I thought I could say:

MUSHClient.exe <WorldFile>

And it would open that world file, and thus be able to get the pref's DB.

But, now that I think about it, that's going to require custom shortcuts as well anyway (1 per MUD), so it's no different that changing the "Start in" portion, so...

Ignore me, I do. =)

Daesilme / Dan
#17
This might seem too late to post this, now that 4.41 is out, but the toolbar details are still stored in the registry (although someone already noted this). Is there any possible way to change this and save those details in the SQLlite file?
Australia Forum Administrator #18
It is fiddly to put the toolbar details into the SQLite database, as this stuff is done by internal libraries. However it was possible to make it not use the Registry. :-)

From version 4.42 onwards, the toolbar details, and the MRU list (Most Recently Used files) are now saved in a file called MUSHclient.INI in the same directory as the working directory when MUSHclient is invoked.

To do this, I had to remove the reference to setting "Gammon Software Solutions" as the Registry key for the program.

The only problem with this is trying to migrate from earlier versions, where people may have stored extensive settings in the Registry.

The sequence at startup is now:

  • Open a file MUSHclient.INI in the startup directory of MUSHclient - this will be used for the toolbar locations and MRU list.
  • Look for the global preferences database (mushclient_prefs.sqlite) in the startup directory.
  • If not found, look for the global preferences database (mushclient_prefs.sqlite) in the MUSHclient application directory.
  • If not found in either place, create the preferences database in the startup directory AND then set the Registry to use the "Gammon Software Solutions\MUSHclient" key to try to locate existing global preferences (created by earlier versions of MUSHclient). Then copy those preferences from the Registry to the SQLite database.


Thus the net effect is that the "Gammon Software Solutions\MUSHclient" Registry key will not be created provided it finds the SQLite global preferences database.