Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ MUSHclient global prefs migrated from Registry to database
MUSHclient global prefs migrated from Registry to database

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Sun 22 Feb 2009 02:34 AM (UTC)
Message
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


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #1 on Sun 22 Feb 2009 02:46 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #2 on Sun 22 Feb 2009 02:59 AM (UTC)
Message
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.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #3 on Sun 22 Feb 2009 05:14 AM (UTC)
Message
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.
Top
Posted by Onoitsu2   USA  (248 posts)  Bio
Date Reply #4 on Sun 22 Feb 2009 06:06 AM (UTC)
Message
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
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #5 on Sun 22 Feb 2009 08:13 AM (UTC)
Message
.. 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.
Top
Posted by Artel   USA  (65 posts)  Bio
Date Reply #6 on Sun 22 Feb 2009 06:45 PM (UTC)
Message
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.
Artel.
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #7 on Sun 22 Feb 2009 07:15 PM (UTC)
Message
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. :)
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #8 on Sun 22 Feb 2009 10:49 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #9 on Mon 23 Feb 2009 01:31 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #10 on Mon 23 Feb 2009 02:00 AM (UTC)
Message
http://en.wikipedia.org/wiki/Desktop_Window_Manager


It's the Bloatware that gives you the Aero interface.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #11 on Mon 23 Feb 2009 02:10 AM (UTC)
Message
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. :
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #12 on Mon 23 Feb 2009 02:15 AM (UTC)
Message
Right, cuz Gnome isn't a bloated piece of wonky junk either. ;) Same function.

(I prefer XFCE & Xubuntu.)



Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #13 on Mon 23 Feb 2009 06:06 AM (UTC)
Message
.. 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.)
Top
Posted by Daesilme   USA  (2 posts)  Bio
Date Reply #14 on Mon 23 Feb 2009 01:11 PM (UTC)
Message
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
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

58,508 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home