On Fri, 17 Jan 2003 14:21:52 +0100 (CET) <[EMAIL PROTECTED]> wrote: > > no, it's more of a frontend than a configuration program. Let it > > have its own menu entry and when the user starts it and then a > > winexe through it, wine-config will run. Ah, I see, the user might > > be tempted to configure wine before running an exe. Hmm, have to > > think about this. > ok, but using it as a frontend sounds ok to me. Configure wine can be > a menu entry added by the xwine package?
have a look at it, it's really small and doesn't have many dependencies besides GTK. It offers configuration via neat combo boxes and I just noticed it even has a menu entry for launching winesetuptk (if you can push that into contrib). So you can have everything via xwine. http://darken.tuxfamily.org/pages/xwine_en.html i18n support is fairly rudimentary, the pot file created by xgettext is a mess of English and French. But maybe that will change if the app gets some publicity when it makes it into contrib or even the distro. > Solution: 1) write config to globaldir!=windir. If this is possible. that's why I said I don't really know wine registry handling. Getting rid of the separate reg files is on the wine TODO list but who knows when it will be implemented. If globaldir reg means /etc/wine we's have to make it 664 for group wine. Don't know if that's a good idea. > 2) change wine script to copy a fakeglobalreg from > /var/lib/wine/globalreg to userhome dir at start. And copy the, > potentially changed userreg to /var/lib/globalreg at exit. > > Ofcourse, both options are insecure. And user1 can screw user2's > setup. But in windows it is the same. yea, any 3-year old can screw windows :P I think we can postpone this registry stuff, need to test this some more. For the time being, it would be nice to get our patches back into the package. My automount patch shouldn't collide with any other mount method as it basically is only an "if config has automount line then keep drives". - Mark
