Winetools -> wine doors

Hi Karl,
> I would love it if people would get involved, a few good coders can have
> SVN/trac access I'll work on opening up to the public soon.
>
> pygtk/pyxml/wine hackers/shell scripters very welcome.

Maybe I can help with bash scripting (very good skill) .... I know 
nothing about python ... 8( ... but can learn quickly.
      BTW, I would like to point out two suggestions:

1) you (we) should set up a winedoors-devel list. This discussion should 
be out of the wine-devel list (we should not mix things up and wine devel 
folks are already too busy)
2) the winedoors should return some information to the AppDB in order to 
keep that information for the wine devel folks get some feedback what is 
going on with, for example, DLL overrides. For example, if the AppDB keeps 
track of the most overriden DLLs (information "feeded" by winedoors - or 
winetools 8)) I think wine developers could query the database in order to 
see which DLL needs some improvement because its is the most one 
overriden.

One more thing, I like Winetools. It helped me a lot. Does it need 
improvement? Yes, it needs, but it is not the reason we may "burn" it.

Regards (I am not subscribed at wine-devel list, so please cc me)
---------------------------------------------------------
Ulisses de Sousa Penna
Analista Consultor - Banco do Brasil
Fone: [phone]   Fax: [phone]
---------------------------------------------------------

[Tony Lambregts]

[e-mail] wrote:
> Hi Karl,
> > I would love it if people would get involved, a few good coders can have
> > SVN/trac access I'll work on opening up to the public soon.
> >
> > pygtk/pyxml/wine hackers/shell scripters very welcome.
>   Maybe I can help with bash scripting (very good skill) .... I know 
>
> nothing about python ... 8( ... but can learn quickly.
>       BTW, I would like to point out two suggestions:
> - you (we) should set up a winedoors-devel list. This discussion should
>
> be out of the wine-devel list (we should not mix things up and wine devel 
> folks are already too busy)

I do not agree Wine developers can ignore threads that they are not interested 
in if they wish. However they may be interested in development of these 
resources. I look at it as being the same as discussions on bugzilla, winecfg, 
the AppDB or the Wiki.
> - the winedoors should return some information to the AppDB in order to
>
> keep that information for the wine devel folks get some feedback what is 
> going on with, for example, DLL overrides. For example, if the AppDB keeps 
> track of the most overriden DLLs (information "feeded" by winedoors - or 
> winetools 8)) I think wine developers could query the database in order to 
> see which DLL needs some improvement because its is the most one 
> overriden.

I agree that this would be useful to wine developers if the AppDB had this, even 
  if nothing else comes out of this discussion.

One other consideration to take into account when dealing with dll overrides is 
that we cannot assume that everyone is legally entitled to use just any dll. It 
should be the is the responsibility of each individual to make. sure they are 
entitled to use them.
>   One more thing, I like Winetools. It helped me a lot. Does it need 
>
> improvement? Yes, it needs, but it is not the reason we may "burn" it.
> Regards (I am not subscribed at wine-devel list, so please cc me)
>
> Ulisses de Sousa Penna
> Analista Consultor - Banco do Brasil
> Fone: [phone]   Fax: [phone]