On Sunday January 13 2008 12:52:22 Steven Edwards wrote:
On Jan 13, 2008 6:24 AM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
My impression was that Wine follows the requests and demands of Linux (and other supported OSes) users, not the Windows' ones regardless of their powerfulness.
Well most Windows power users are used to a graphical registry editor where Wine supports a text registry and we all know how much Linux users love flat text file manipulation. Perhaps we should revert the graphical registry editor for this and reasons I mentioned in the prior email....
I see no reason to revert currently abailable tools without *really good* technical or legal reason. Sorry but this would be simply... not smart, really. I like the ability to edit registry directly with text editor but this doesn't mean that I don't need GUI tool for that. Reasons are simple: with GUI I have tree with registry keys and with plain text I have sequence of registry keys. I think it is obvious why one would prefer tree instead of sequence in some cases and sequence instead of tree in other cases. BTW, msconfig isn't very popular tool. Just compare how many Windows users have used regedit and how many have used msconfig (and how freqently it is used in comparison with regedit). And of course many Linux users simply don't know about it. This means that even if we include msconfig its use will not be as intuitive as winecfg use for purpose of editing startup keys. Therefore winecfg is better for that purpose. In fact, use of winecfg will be obvious for all WINE users - including Windows power users. If we can include msconfig - good, but in my opinion its inclusion doesn't mean that winecfg shouldn't support editing of startup keys. Therefore, its inclusion or rejection isn't important to WINE Project (in other words, this is minor issue). As I said, winecfg is more convenient and intuitive for that purpose.
If you disagree with WINE policy related to ReactOS you need to talk to AJ directly (for example, on IRC channel). Multiple requests to exclude existing tools on wine-devel without good reasons will not help to make WINE or its current policy better, really.