You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff.
I have almost ready patch. I've attached screenshot. Is it a good idea?
Thanks, Jacek
I guess so - please send this patch to me ASAP as I was planning on hacking winecfg a bit next week (dunno if I'll have time but ...) so it'd be nice if I could work from latest sources.
I'm not really convinced that being able to configure these paths is a useful thing but I guess if people want to use a real Windows drive it may be handy.
thanks -mike
On Sun, 15 Aug 2004 14:29:24 +0000, Jacek Caban wrote:
You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff.
I have almost ready patch. I've attached screenshot. Is it a good idea?
Thanks, Jacek
Mike Hearn mike@navi.cx writes:
I guess so - please send this patch to me ASAP as I was planning on hacking winecfg a bit next week (dunno if I'll have time but ...) so it'd be nice if I could work from latest sources.
I'm not really convinced that being able to configure these paths is a useful thing but I guess if people want to use a real Windows drive it may be handy.
No, I don't think we want to make the paths configurable that way. At least for the windows and system dirs, they will most likely be embedded in the registry somewhere so you can't change them without reinstalling everything; and there's no real reason to anyway. What we should have is a "import real Windows drive" button that lets you point to a Windows partition and set things up properly based on that.
Alexandre Julliard wrote:
Mike Hearn mike@navi.cx writes:
I guess so - please send this patch to me ASAP as I was planning on hacking winecfg a bit next week (dunno if I'll have time but ...) so it'd be nice if I could work from latest sources.
I'm not really convinced that being able to configure these paths is a useful thing but I guess if people want to use a real Windows drive it may be handy.
No, I don't think we want to make the paths configurable that way. At least for the windows and system dirs, they will most likely be embedded in the registry somewhere so you can't change them without reinstalling everything; and there's no real reason to anyway. What we should have is a "import real Windows drive" button that lets you point to a Windows partition and set things up properly based on that.
But PATH and temp directory are useful and can be configured this way. Maby we could add this two options?
Thanks, Jacek
Jacek Caban jack@itma.pwr.wroc.pl writes:
But PATH and temp directory are useful and can be configured this way. Maby we could add this two options?
I don't think they really need to be configured, at least not often enough to put them in winecfg. There's no real reason to change the temp directory, and if an app needs a different PATH the installer for that app will change the registry itself. If users really need to change them, IMO we are doing something wrong.
On Mon, 16 Aug 2004, Alexandre Julliard wrote:
Jacek Caban jack@itma.pwr.wroc.pl writes:
But PATH and temp directory are useful and can be configured this way. Maby we could add this two options?
I don't think they really need to be configured, at least not often enough to put them in winecfg.
That is the case about ordinary users.
There's no real reason to change the temp directory,
Actually, there are some reasons for power-users. One of them which hits eme is the low emtpy space on mounted partitions. When I am installing some big software I usually change the %temp% dir by editing ~/.wine/config to point it to the FS wich has enough free-space. When a new disks and partitions on my machine are going in and out I need to do the same.
While using "config" file is fine, it doesn't feel for me comfortable to use "regedit". :-P
and if an app needs a different PATH the installer for that app will change the registry itself. If users really need to change them, IMO we are doing something wrong.
Or users may be using not an ordinary softw. or may be even developing / debugging it inside the Wine, IMHO. I haven't been changing the %PATH% dir too often, but there are some console win32 utilities, made by me and such which have no installer. So, if I need to run them from the batch file at wcmd, I basically need to modify %PATH%.
Again, this may be need by power-win32-users, who basically can't stand the GUI of "regedit". :-P
PS maybe an alternative for the "winecfg" may be some cmd-line option like the "/advanced" to make such functionality available to user at run-time?
Sorry for being a bit unclear:
On Tue, 17 Aug 2004, Saulius Krasuckas wrote:
On Mon, 16 Aug 2004, Alexandre Julliard wrote:
and if an app needs a different PATH the installer for that app will change the registry itself. If users really need to change them, IMO we are doing something wrong.
..
but there are some console win32 utilities, made by me and such which have no installer. So, if I need to run them from the batch file at wcmd, I basically need to modify %PATH%.
That's because there are quite a lot of utilities and I am hardly going to rewrite the batch file to call the programs using their full path.
Again, this may be need by power-win32-users, who basically can't stand the GUI of "regedit". :-P
By definition, Windows power users are comfortable with the registry, as how else did they get to be power users in the first place?
PS maybe an alternative for the "winecfg" may be some cmd-line option like the "/advanced" to make such functionality available to user at run-time?
No, a totally undiscoverable "advanced" mode is worse than just regedit. Even an "advanced" button is bad: this sort of UI thinking is not one we wish to copy IMHO.
Sorry, but I don't see what your hangup over the registry is. Remember the .reg files are plain text! You can edit them in whatever editor you like (as long as no wine processes are running at the time, of course).
On Tue, 17 Aug 2004, Mike Hearn wrote:
Again, this may be need by power-win32-users, who basically can't stand the GUI of "regedit". :-P
By definition, Windows power users are comfortable with the registry, as how else did they get to be power users in the first place?
Ughm, maybe I meant not-so-power users? :-/
Yes they are comfortable with browsing the registry, but they aren't such with editing it. At least I am not.
PS maybe an alternative for the "winecfg" may be some cmd-line option like the "/advanced" to make such functionality available to user at run-time?
No, a totally undiscoverable "advanced" mode is worse than just regedit.
Ok, I agree. That is a M$ way. It is not nice.
Even an "advanced" button is bad: this sort of UI thinking is not one we wish to copy IMHO.
Button is wrong definitely, it is not needed for the most of the users. And some additional edit-boxes
Sorry, but I don't see what your hangup over the registry is. Remember the .reg files are plain text! You can edit them in whatever editor you like (as long as no wine processes are running at the time, of course).
Right, I am forgetting about this. And the difference is in the size of the files:
[s2@katleriai SRPMS]$ wc -l ~/.wine/config ~/.wine/system.reg 256 /home/s2/.wine/config 4946 /home/s2/.wine/system.reg 5202 total
Text editor for the registry tweaking isn't an easy choice for me, because I don't like searching for one particular line through the 5000 of others.
What then should I do walking this way is:
1, to export file; 2, to edit it; 3, import it back.
Or in a bash-awk code:
#!/bin/bash PATH_REG=tmp.reg PATH_BRANCH='HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' AWK_APPEND_NPATH='{if (match($0,/^"PATH"=/)) sub(/"\r/, ";"ENVIRON["NPATH"]"""); print}' NPATH='a:\new\path'
if [[ "$1" == "" ]]; then { echo Example of a usage : $0 '$NPATH' exit 1 } fi
if regedit /E $PATH_REG "$PATH_BRANCH"; then { export NPATH="$1" if cat $PATH_REG | awk "$AWK_APPEND_NPATH" > $PATH_REG; then { regedit $PATH_REG cat $PATH_REG | grep ^"PATH | xargs echo "Setting this: " rm $PATH_REG } fi unset NPATH } fi
Right, I am forgetting about this. And the difference is in the size of the files:
[s2@katleriai SRPMS]$ wc -l ~/.wine/config ~/.wine/system.reg 256 /home/s2/.wine/config 4946 /home/s2/.wine/system.reg 5202 total
Text editor for the registry tweaking isn't an easy choice for me, because I don't like searching for one particular line through the 5000 of others.
What then should I do walking this way is:
1, to export file; 2, to edit it; 3, import it back.
Maybe we should fork the Wine/Config branch into a separate .reg file to appease those who want to edit it using a text editor. That would make the switch from config file -> registry less obvious. Not exactly the same of course, no comments for one, no defaults to show you what they are for another, but it might be an improvement?
On Tue, 17 Aug 2004, Mike Hearn wrote:
256 /home/s2/.wine/config4946 /home/s2/.wine/system.reg
...
Maybe we should fork the Wine/Config branch into a separate .reg file to appease those who want to edit it using a text editor. That would make the switch from config file -> registry less obvious. Not exactly the same of course, no comments for one, no defaults to show you what they are for another,
Right, the clear Wine REG-file format only (in a separate file).
but it might be an improvement?
I think yes, for me it would an improvement. The only bad thing here is my lack of the ideas on how to implement such forking.
If it is a not very trivial stuff to code and if only a very few users would become pleased with it, then the idea is dead already, right?
Whatever it be, I vote for the forking offered by Mike: config-to-registry-through-a-separate-regfile, eg.: ~/.wine/config.reg .
PS I know, my english isn't OK. Hope I can be understood in right way.
I think yes, for me it would an improvement. The only bad thing here is my lack of the ideas on how to implement such forking.
We already do it for user.reg vs system.reg, though in this case it's separate registry "hives". I'm not sure if we can do it on the key level.
I'm certainly not bothered by this, and I think when people realise they hardly ever have to configure Wine it'll all blow over, but if somebody else wants to do the patch be my guest ...
How about the Debian way of adding stubs to a .d directory...
wine.d with lots of small easily editable .reg files. I'm sure this is a silly suggestion, but if you REALLY have a problem with a 5000 line .reg file (I sure did when I had to configure squid.. uggh), nothing prevents you from doing this yourself and having a update-wine.conf script, Debian style (refering to their exim4 setup).
Mike Hearn wrote:
Maybe we should fork the Wine/Config branch into a separate .reg file to appease those who want to edit it using a text editor. That would make the switch from config file -> registry less obvious. Not exactly the same of course, no comments for one, no defaults to show you what they are for another, but it might be an improvement?
On Wed, 18 Aug 2004, Izak Burger wrote:
How about the Debian way of adding stubs to a .d directory...
wine.d with lots of small easily editable .reg files. I'm sure this is a silly suggestion, but if you REALLY have a problem with a 5000 line .reg file (I sure did when I had to configure squid.. uggh), nothing prevents you from doing this yourself and having a update-wine.conf script, Debian style (refering to their exim4 setup).
I have never been using the Debian distro and have no experience with a .d directories. Is there any newbie intro to this stuff on the net? Thanks.
Mike Hearn wrote:
Maybe we should fork the Wine/Config branch into a separate .reg file to appease those who want to edit it using a text editor. That would make the switch from config file -> registry less obvious. Not exactly the same of course, no comments for one, no defaults to show you what they are for another, but it might be an improvement?
I'm not too sure it will work for wine, it was just a wild suggestion.
Debian uses it to get arround the problem of modifying certain config files. For example, if you install the nvidia drivers, you have to modify /etc/modules.conf. The usual way is to employ some perl or some other magic to add the line to the file, but Debian adds a file to /etc/modutils, and then runs the update-modules. The idea is that every small file in /etc/modutils contains only the lines relevant to the package it was installed by, and the modules.conf file is generated from these small files (in this case, by simply concatenating them together).
The debian exim4 package has a similar setup (it is optional, if you want one big file you can still have it), but because exim4's config file has different sections, they have a directory for each section, with small files that are concatenated to make up the sections, and then the sections are assembled together to make a config file. Once again, say I install an antivirus like clamav or a spam checker like spamassassin, these packages need only drop a small file with their config settings into the correct directory and run the script update-exim4.conf to make a new config file.
Now since the registry is just text in wine, and according to the feature we are talking about (splitting the old config stuff into a seperate reg file) this could work, but the reason why I said it is silly is because this would make editing of the registry with regedit an absolute mess, because 1) you will be editing the autogenerated file (and not the orriginal stubs) and 2) even if you could trace the way back to the original stubs, it just complicates matters unnecessarily.
To split, or not to split, that is the question :-)
It was a silly suggestion, but it would be an option so split seperate parts of the registry into seperate files if it REALLY becomes too unmanagable. But if you've ever had to configure squid, with it's default config file of several hundred lines, I'm sure you'll find this not to be such a big issue.
Sometimes I should just shut up, I'm sure one of the _real_ developers will be along shortly to tell me why :-)
Cheers, Izak
Saulius Krasuckas wrote:
On Wed, 18 Aug 2004, Izak Burger wrote:
How about the Debian way of adding stubs to a .d directory...
wine.d with lots of small easily editable .reg files. I'm sure this is a silly suggestion, but if you REALLY have a problem with a 5000 line .reg file (I sure did when I had to configure squid.. uggh), nothing prevents you from doing this yourself and having a update-wine.conf script, Debian style (refering to their exim4 setup).
I have never been using the Debian distro and have no experience with a .d directories. Is there any newbie intro to this stuff on the net? Thanks.
Mike Hearn wrote:
Maybe we should fork the Wine/Config branch into a separate .reg file to appease those who want to edit it using a text editor. That would make the switch from config file -> registry less obvious. Not exactly the same of course, no comments for one, no defaults to show you what they are for another, but it might be an improvement?
(Sorry, wrong key-press)
On Tue, 17 Aug 2004, Saulius Krasuckas wrote:
Or in a bash-awk code:
#!/bin/bash PATH_REG=tmp.reg PATH_BRANCH='HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' AWK_APPEND_NPATH='{if (match($0,/^"PATH"=/)) sub(/"\r/, ";"ENVIRON["NPATH"]"""); print}' NPATH='a:\new\path'
...
And this is kind of messy. But nevermind, I am sure I am one of those exceptional users, so.. Thanks for the feedback.
-
Alexandre Julliard -
Izak Burger -
Jacek Caban -
Mike Hearn -
Mike Hearn -
Saulius Krasuckas