One more thing, it seems that the use of currprefs and changed_prefs is not very consistent (at least in the gtk frontend)
for instance modifying mountinfo is directly on currprefs, the frontend mentions that the emulator makes a copy of the currprefs.mountinfo at startup so they can edit currprefs directly... i'm doing it that way too now, but is it k if i let the qt frontend solely operate on changed_prefs ? seems cleaner
to me kind regads, Ivo Couckuyt Ivo Couckuyt wrote:
Richard Drummond wrote:Here it is not so polite just calling unknown persons by their first name :-) Though I admit I better used Mr. Drummond, but then again. that's so formal. So i'll try to remember to use the first name :-)Hi Ivo On Thursday 07 June 2007 04:21:41 Ivo Couckuyt wrote:Drummond: perhaps you can enlighten some bits of the meaning of currprefs, changedprefs ? would be easier than figuring it out on my own :)I have a first name, you know. Calling me 'Rich' is quite acceptable. In fact, in English calling somebody by their surname without an honorific of some kind (Mr., Dr., whatever) is usually considered rude. Just so you know. ;-)ah, and don't be fooled by the e-mail address (.co.uk), I am from Belgium... :DI thought so, but i couldn't find any semaphore code in the gtk frontend that restricted the access to changed_prefs (in case uae was copying...).To answer your question:currprefs is the current configuration state as seen by the emulator proper. changed_prefs is the current configuration state as chosen in the configuration GUI. When the emulator is running, these may differ. The emulator compares the two periodically. It's in this way that it notices and reacts to any changes in settings that the user may have made. After acting on such a change, it sets currprefs = changed_prefs again.I don't much like the system (lots of redundant comparisons between currprefs and changed_prefs), but it's what we inherited from UAE. It'll get it fixed one day...thanks.Cheers, Rich
