Mike Hearn wrote:
Eventually nobody should have to use winecfg for anything. Let's spend our
time fixing the bugs and increasing automation rather than arguing about
the best way to represent a list of hacks in the UI :)
I think the reality is that winecfg is going to hang round for a while.
I was just wondering about this new system of doing things. I quite like
the new config method. It doesn't allow the indepth configuration that
the old .config file did but I'm sure thats not going to be a problem.
I was thinking though, will windows programs have access to these
configuration
On Mon, 2005-07-11 at 13:09 +0100, Adam Cooper wrote:
I was thinking though, will windows programs have access to these
configuration registry entries? Or are they somehow protected. If any
windows program can view these entries then they could perhaps refuse
to install. i.e. Valve decide HL3
Mike Hearn wrote:
Eventually nobody should have to use winecfg for anything. Let's
spend our
time fixing the bugs and increasing automation rather than arguing about
the best way to represent a list of hacks in the UI :)
I think the reality is that winecfg is going to hang round for a
On Monday 11 July 2005 23:25, gslink wrote:
Mike Hearn wrote:
Eventually nobody should have to use winecfg for anything. Let's
spend our
time fixing the bugs and increasing automation rather than arguing
about the best way to represent a list of hacks in the UI :)
I think the
It seems that the native only choice doesnt work into winecfg -
I tried to set one dll as 'Native(Windows)' and got native,builtin into the
registry.
Could you have a look for this ?
--- Felix Nawothnig [EMAIL PROTECTED] a écrit :
Brian Vincent wrote:
What may not be obvious is the
Sylvain Petreolle wrote:
It seems that the native only choice doesnt work into winecfg -
I tried to set one dll as 'Native(Windows)' and got native,builtin into the
registry.
Could you have a look for this ?
Works fine for me...
Felix
Mike Hearn [EMAIL PROTECTED] writes:
Eg, even Windows Version will hopefully be fixed sometime later this
year (?) by switching us to 2K/XP mode by default and by nailing the last
DCOM problems.
Actually we probably want to do that before 0.9, which means real soon
now...
Desktop mode will
Is there a way to cause winecfg to assume the contents of the config
file on initiation?
Brian Vincent wrote:
On 7/8/05, Hiji [EMAIL PROTECTED] wrote:
How are DLL overrides done in winecfg?
What may not be obvious is the "Applications" tab in winecfg is tied
to the
Hiji schreef:
--- Dan Sawyer [EMAIL PROTECTED] wrote:
All,
I am testing with the wine 2005 release. The release
notes state config
file control has been moved to the registry and that
winecfg is active.
winecfg does not seem to recognize dll overrides.
Has anyone else seen
this? If so
On Sat, 09 Jul 2005 07:01:16 +0200, Felix Nawothnig wrote:
I'll submit a preliminary patch (introducing the not yet configurable
DSound settings) showing how I think this should be done later today.
Felix and I talked this stuff over on IRC, I think we came to some
understanding on where
--- Dan Sawyer [EMAIL PROTECTED] wrote:
All,
I am testing with the wine 2005 release. The release
notes state config
file control has been moved to the registry and that
winecfg is active.
winecfg does not seem to recognize dll overrides.
Has anyone else seen
this? If so were you
On 7/8/05, Hiji [EMAIL PROTECTED] wrote:
How are DLL overrides done in winecfg?
What may not be obvious is the Applications tab in winecfg is tied
to the other tabs. We should probably add a sentence in the
description of that tab to briefly explain it links to other ones
(inc. Graphics). In
Brian Vincent wrote:
What may not be obvious is the Applications tab in winecfg is tied
to the other tabs.
The current design is totally braindead from a usability standpoint:
* As you pointed out it's not very intuitive that selecting an item in
the first tab affects the semantics of the
14 matches
Mail list logo
