Oops, didn't search thoroughly enough...
I found the winecfg program. It isn't finished though...
Are you guys still working on it?
Did you also experience that it says "Unable to set configuration key" for anything you'd try to change?
Didn't you finish it yet because you need some other library to be built first, or just because you didn't have the time yet?
Grtz, Robert
On Sun, 2003-12-28 at 10:27, Robert van Herk wrote:
Oops, didn't search thoroughly enough...
Oops, should read all mail before replying :)
I found the winecfg program. It isn't finished though...
Are you guys still working on it?
No, at the moment nobody is working on it.
Did you also experience that it says "Unable to set configuration key" for anything you'd try to change?
Ah, well basically you need to change the header to point to a winecfg specific registry branch. The way config in wine works is like this:
* config file is a registry file * On wineserver startup (of course the wineserver manages registry access) the config file is loaded as a special, read only, branch of the registry. * Parts of Wine read from the config file by using the registry APIs
However, the config file branch is still special and read only. When winecfg is ready, we'll switch off config file loading (except for special cases like migration of old settings) and the config branch will become a normal read/write one, and then winecfg will work correctly.
For now, you just need to change where winecfg points in your local tree so it can read/write (but it will think you have no pre-existing config which is good for catching bugs too). The string you want is at the bottom of winecfg.h, I change it to Software/Wine/WineCfg
Didn't you finish it yet because you need some other library to be built first, or just because you didn't have the time yet?
I ran out of time/motivation. It takes quite a lot of work! I hope to go back at some point but currently other stuff is higher on my todo list (like getting systray integration merged).
thanks -mike
Did you also experience that it says "Unable to set configuration key" for anything you'd try to change?
Ah, well basically you need to change the header to point to a winecfg specific registry branch. The way config in wine works is like this: ...<SNAP>
Okay I'll give it a try.
I was just thinking: from the wine documentation I figured that every global setting could be overwritten with an application specific setting, right? This is said - kinda informally - in http://www.winehq.org/site/docs/wine-user/config-file, in the table in the section "What does it contain".
But from what I see in your program, I would say that that wouldn't work currently with your lay-out, since Applications is just done on 1 tab sheet. Am I missing something? If not, did you do this on purpose, for example because you would prefer user friendliness above completeness?
Would it make sence to alter the program in such a way, that first you choose for what part you want to change something (either global or a specific application) and then, on a second frame/form/window (I don't know which word to use in this context), really do the changes, kinda like the Network setup works in Win95?
I mean: there you first select the protocol you want to change, and then a new window opens in which you do the settings themselves... Would that be a good idea?
Grtz, Robert
On Sun, 2003-12-28 at 16:28, Robert van Herk wrote:
I was just thinking: from the wine documentation I figured that every global setting could be overwritten with an application specific setting, right? This is said - kinda informally - in http://www.winehq.org/site/docs/wine-user/config-file, in the table in the section "What does it contain".
No, not every setting (that would not make sense). Some can though, for instance some x11drv settings and dll overrides.
But from what I see in your program, I would say that that wouldn't work currently with your lay-out, since Applications is just done on 1 tab sheet.
Well, the way it works is that you select the app you want to edit and then change to other tabs. Yes, the UI for this is not the best.
Long term my plan was this:
* Remove usage of the PropertySheet API, and just use a standard win32 tab sheet * Move the app/global ui into a nice header at the top of the window that is always visible * Fix up the instant apply vs explicit apply stuff to be more complete * Complete all the settings.
App vs global editing *does* work, try changing it to an app specific entry in the Apps tab then altering desktop mode. You should find you can scope it to the app.
-
Mike Hearn -
Robert van Herk